Open Stack

On 05/03/2014 12:48 AM, Mark T. Voelker wrote:
> I think it's not just devstack/grenade that would benefit from this.
> Variance in the plugin configuration patterns is a fairly common
> complaint I hear from folks deploying OpenStack, and going to a single
> config would likely make that easier.  I think it probably benefits
> distributions too.  There have been several issues with distro init
> scripts not properly supplying all the necessary --config-file
> arguments to Neutron services because they're not uniformly pattered.

With my OpenStack Debian package maintainer hat on...

TL;DR: Moving to a single configuration file is unimportant for me, what
I would like is configuration files that I can easily parse.

Longer version:

The issue hasn't been multiple configuration. I've dealt with that by
parsing the core_plugin value, and do what should be done in the init
script depending on that.

The main issue with current configuration files is that they are *not*
parser friendly. Eg, there stuff like:

# Example:
# directive = value
#directive=<None>

A script cannot make the difference between the first and the 2nd
instance of the directive, and it's like this all over the place in
Neutron configuration files. Something like this:

sed -i "s/[ \t#]*directive[ \t]*=.*/directive = newvalue/" \
		/etc/neutron/neutron.conf

which I extensively use (well, it's a little bit more complicated as
what I do doesn't show in /proc: for security purposes, directives
values shouldn't show in a ps, but you got the point...).

Even worse, there's some huge example snippet which I had to delete (for
the same parseability reasons). These belong in the openstack-manuals,
or in the sphinx doc, *not* in a configuration files.

So for me, parseability should be addressed with top priority. I am
currently patching the neutron configuration files because of this, and
I have to constantly rebase my debian-specific patches, that's boring,
and error prone. I'd very much prefer generated configuration files like
for other projects instead (on a single or multiple configuration files:
I don't care since I have the logic already implemented...).

Cheers,

Thomas Goirand (zigo)