Open Stack

On 24/06/20 10:51 am, Thomas Goirand wrote:
>> If we want to attract new UI developers, we have to switch to new
>> technologies which are a standard in a world of web development.
> I'm really not convinced by that point of argumentation. It has been
> written in this tread multiple times, but I don't see why switching
> technology spawns new contributors out of nowhere.
There aren't many AngularJS devs around anymore, and the two external
contractors we (Catalyst) brought in to do work with some Horizon
plugins for us had a hell of a time with the codebase. Not to mention I
bet very few of the existing devs who touch Horizon (myself included)
want to seriously learn AngularJS given it's an EoL framework. Plus I
avoid some features I want to do purely because it's so hard given the
current codebase.

I've found ways to work with Horizon that make my life, and other devs
working with me a little easier, but right now it's still not great, and
that itself is a barrier to entry. It's very very hard to get anyone
really enthusiastic about working on Horizon. :(
> Though, as an operator, I really would prefer the switch from
> local_settings.py to a normal .ini to move forward. That's IMO more
> important than any internal redesign. Horizon is a real pain to
> configure (from both the package maintainer perspective with plugins,
> and from the configuration management side (puppet in my case)). Do we
> have any hope with this for Victoria?
I would be the first person to raise my hand and argue against that. A
lot of the settings Horizon (and Django) has are nested dictionaries, or
structures which do not lend themselves at all to .ini style settings
files. Not to mention in our own deployment of Horizon our custom
local_settings.py has logic in it, and reads most config from envvars
with internal conditions for some settings based on what is read in.

I built Adjutant using Django, and while a python file as config is
common for Django applications, I did opt for using .yaml (and soon toml
as well) instead, with my django settings.py file pulling values from my
config layer that Django needs. Horizon 'could' do something similar,
but it would likely be best to do .yaml or .toml, not .ini simply
because the lack of good dict support.

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. If it really is that
painful for you, it is just python, you can easily enough make a custom
local_settings.py that imports your primary settings from an .ini file
of your choice/design! :P