Open Stack

On Tue, Jul 23, 2013 at 6:55 AM, Emilien Macchi <emilien.macchi at enovance.com
> wrote:

>  Also for your information,
>
> I created a bug : https://bugs.launchpad.net/neutron/+bug/1199963
> and a first patchset for generating the new configuration file with Oslo
> config scripts :
> https://review.openstack.org/#/c/36546/
>
> Emilien Macchi
> ----------------------------------------------------
> # OpenStack Engineer
> // eNovance Inc.              http://enovance.com
> // ✉ emilien at enovance.com     ☎ +33 (0)1 49 70 99 80
> // 10 rue de la Victoire 75009 Paris
>
> On 07/22/2013 06:34 PM, Julien Danjou wrote:
>
> Hi there,
>
> I've been working on the changes that would need to be done to make the
> default config generator work for Neutron.
>
> However, the current default config generator doesn't support the
> possibility to generate different configuration files (e.g. one per
> service/plugin). I can imagine two options:
>
> a. move every options in oslo.config.cfg.CONF, moving the plugins into
>    their own section rather than in their own file, register all options
>    at module-level, avoiding duplicate options.
>
> b. enhance config.generator to generate a config file from a particular
>    object (not always olso.config.cfg.CONF like it's done currently).
>    That means Neutron should evolve to provide a global CONF object per
>    plugin at least.
>
>
Actually the current generator script looks for an instance or a list of
instances of classes which are inherited from cfg.Opt. For example, if
module a.py has

_opt = cfg.StrOpt(a)
_opts = [
    cfg.IntOpt(b),
    cfg.BoolOpt(c),
]

Then the generator.py catches _opt and _opts and prints the config info
onto the config file.
The group info of a particular option is searched in oslo.config.cfg.CONF.

>
> Option a. is how all other OpenStack projects¹ are working so far.
> Option b. requires a bit more work on both side.
>
> Is there any particular way you guys see things?
>
> IMO, we shouldn't change how Neutron uses its config files due to
backwards compatibility issues. I was thinking of each project having a
openstack-config.conf file (like openstack-common.conf) which contains the
mapping of options to config file names.
Then the generator.py will load the openstack-config.conf file and generate
config files accordingly. An exception will be raised If an option is
neglected in openstack-config.conf

But whatever path we take, it would be hard to land a perfect solution
within Havana. So I suggest we first stick with neutron.conf.sample for now.

>
> ¹  nova, ceilometer and heat at least for now
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing listOpenStack-dev at lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
*Intel SSG/STOD/DCST/CIT*
880 Zixing Road, Zizhu Science Park, Minhang District, 200241, Shanghai,
China
+862161166500
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130723/1a55b774/attachment.html>