On Fri, 2020-06-26 at 10:21 +0200, Radomir Dopieralski wrote:
On Fri, Jun 26, 2020 at 9:28 AM Thomas Goirand <zigo@debian.org> wrote:
On 6/25/20 2:00 AM, Adrian Turjak wrote:
On 24/06/20 8:34 pm, Thomas Goirand wrote:
On 6/24/20 4:40 AM, Adrian Turjak wrote:
But of all the things to change, the config layer is the least of our problems in Horizon, and with a good erb template (or jinja with ansible) I have never had much pain with it.
The biggest issue with a .erb template, is that it quickly gets outdated, and needs care for each new version of Horizon. I felt that pain multiple times recently.
But that happens for every service adding new config really.
No. Other services using .ini have a default option embedded it the code itself (ie: that's how oslo.config works...), so if the option isn't there in the config file, it continues to work. This isn't the case with Horizon.
Wait, what? Are you sure we are talking about the same Horizon? It has defaults exactly the same way, and it literally works with an empty local_settings.py.
just as an aside if the direction of this tread is to start a parralel project to create a more moderen openstack dashboard. before selecting any framework i would suggest doing a review of several options and if that is done i would suggest that flutter https://flutter.dev/ be consider since iw toul provide a way to have a singel codebase that will work acorss mobile(ios and android), https://flutter.dev/web and eventually https://flutter.dev/desktop. react vue.js patternfly all have there merrits too but if you are going to embark on this it might be nice to create something that is accessble across many devices at the same time if it does not significantly increase the burden to do so.