[openstack-dev] [TripleO] [Horizon] [Tuskar] [UI] Horizon and Tuskar-UI merge
mrunge at redhat.com
Tue Dec 17 08:41:34 UTC 2013
On 12/17/2013 09:04 AM, Thomas Goirand wrote:
> I think the "disabled by default" approach is the wrong one. Instead, we
> should have some users with enough credentials that will have the
> feature, and others will not.
> Also, Horizon is a web interface. Most of its switches could be made
> directly in the web interface, with the values stored in a db. That'd be
> so much nicer than stored in localsettings.py which starts, as time
> passes, to become overly complicated and ugly (it should, by the way, be
> a configuration file, not a python script: you can't expect
> administrators to understand python, but you do expect them to
> understand how to write in a .ini file).
> Also, it seems we have a consensus, when is it expected to happen? For
> Icehouse b2 maybe?
> Just my 2 cents,
The issue is, that you can not do anything with it, when it's not
configured. The other thing: When you're up to try it, you need quite a
few machines (to install OpenStack on them) etc.
Thus I think, disabled by default is the best way to not to confuse
people, since you now need to know, what you're doing.
We might/should rethink this decision in the future.
The other suggestion (totally unrelated to Tuskar) you had was: to store
config data in a database instead of a (python) config file.
Currently, Horizon does not require a database, and I'd love to keep it
that way. There are currently two configs to be changed once, when
configuring the Dashboard: ALLOWED_HOSTS and OPENSTACK_HOST. The first
is to configure the host to run on, the other points to keystone. This
gets you up and running.
We're inheriting config file handling from Django, and this consists on
parsing python files.
But, if you look at
you'll see a more .ini-file approach, probably more like you were thinking.
More information about the OpenStack-dev