Open Stack

On 05/02/2014 10:09 PM, Mark McClain wrote:
> We have grown in the number of configuration files and I do think
> some of the design decisions made several years ago should probably
> be revisited.  One of the drivers of multiple configuration files is
> the way that Neutron is currently packaged [1][2].

Been there, done that (in Debian), and ... reverted!

I had one package per pluggin back in the Folsom release. This was just
horrible to maintain. Since then, I moved away from that and I have the
following:

- All python files are in python-neutron (yes, including *all* plugin
scripts)
- All configuration files are in neutron-common (yes, including *all*
plugin files)

I just maintain some Provides: neutron-*-plugin in neutron-common to
retain compatibility with Ubuntu (for those using puppet on both Debian
and Ubuntu, not diverging too much is important). But if Ubuntu decided
to move away from that, then I would remove the Provides: everywhere.

Also, discussing with James Page on IRC, he wrote to me that he wouldn't
mind adopting the current Debian design in Ubuntu as well, since it
created useless issues to care in Ubuntu.

So, the distribution point of argumentation is IMO not valid.

Well... *nearly*. The only valid point that I would see for packaging
plugins in separate packages, is that it makes it possible to have
rootwrap specific configuration files, meaning tightened security. But
IMO, this shouldn't be the worries of package maintainer, but rather
Neutron or rootwrap itself handing the size of the root access surface,
depending on the plugin.

On 05/02/2014 10:09 PM, Mark McClain wrote:
> I’d like to see Neutron changed to be a single package similar to the
> way Cinder is packaged with the default config being ML2.

I very much welcome you to use my packages then! :)

On 05/02/2014 10:09 PM, Mark McClain wrote:
> To throw something out, what if moved to using config-dir for
> optional configs since it would still support plugin scoped
> configuration files.
>
> Neutron Servers/Network Nodes
> /etc/neutron.d
> 	neutron.conf  (Common Options)
> 	server.d (all plugin/service config files )
> 	service.d (all service config files)

Please, don't just reinvent the wheel for the sake of it. Either we keep
the current plugin directory thing, or we move to a flat single file
thing. But something like the above would be annoying, IMO. I'd have to
rewrite the init script to handle files in server.d and all, when the
plugin dir logic is already implemented. I don't really want to have fun
re-implement something different again, just because it feels more
pretty (IMO, it's not).

Note that currently, the init scripts are also parsing the core_plugin
directive in neutron.conf. If we add a server.d with it's content being
a moving target depending on the plugin, then it's going to be hell on
the packaging side to make it work out of the box *AND* continue to be
Debian policy compliant (eg: it'd be very difficult for the Debian
postinst script to know when to drop files in the conf.d, and when to
delete them, then I'll have to move to something like apache with
conf.d-available stuff with a symlink farm, which is IMO over-engineered).

On 05/05/2014 12:49 AM, Armando M. wrote:
> If the consensus is to unify all the config options into a single
> configuration file, I'd suggest following what the Nova folks did with
> [1],

Well, I would suggest *not* to follow what Nova guys did, which is to
*not* ship a default configuration file, and let me play with horrible
tox hack to generate one myself (and manually add it to my package).
Please continue to store a default configuration file in the Git!!!

Cheers,

Thomas Goirand (zigo)