On Tue, Jul 23, 2013 at 6:55 AM, Emilien Macchi <emilien.mac...@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 > // ✉ emil...@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@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@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
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
