Excerpts from Kendall J Nelson's message of 2016-01-06 13:07:30 -0600: > Hey Doug, > > This definitely sounds like something to look into. Would you be > interested in being a part of a panel at the upcoming summit in Austin to > discuss this?
I'm not sure what you mean by "panel." Are you planning a cross-project design session? Doug > > All the Best, > > Kendall J. Nelson > Software Engineer & > OpenStack Contributor > > > > > > > E-mail: kjnel...@us.ibm.com IBM > Cell Phone: (952) 215- 4025 > IRC Nickname: diablo_rojo 3605 Hwy 52 N > Rochester, MN > 55901-1407 > United States > > > > > > > > From: Doug Hellmann <d...@doughellmann.com> > To: openstack-dev <openstack-dev@lists.openstack.org> > Date: 01/06/2016 01:03 PM > Subject: Re: [openstack-dev] [all] Austin Summit Panel on Generation of > Sample Configuration Option Files > > Excerpts from Jay S. Bryant's message of 2016-01-05 13:55:30 -0600: > > Ben, > > > > Please see my in-line responses ... > > > > On 01/04/2016 05:43 PM, Ben Nemec wrote: > > > On 01/04/2016 03:50 PM, Kendall J Nelson wrote: > > >> Hello, > > >> > > >> > > >> In brainstorming ideas for talks at the upcoming summit, I thought > about > > >> some of the things I had worked on for Cinder and what could still be > > >> improved. One of the things I have been looking into is the generation > > >> of sample configuration option files. Upon initial research it looks > > >> like none of the main projects are doing it the same way. > > > I'm not sure what you mean. Nova, Neutron, Keystone, Glance, and Heat > > > (at least) are all using the oslo-config-generator tool for this. > There > > > might be some slight variation in how they call it, but they are using > it. > > Yes, we know that they are all using oslo-config-generator but there is > > not consistency > > in how the information that oslo-config-generator needs to do its job is > > being created. > > Kendall is looking to better understand what we should be doing and try > > to bring > > greater consistency between the projects. > > > > > I only vaguely recall having discussions about this with Cinder, so I'd > > > be interested in a refresher around why Cinder didn't want to do it the > > > same way. I kind of considered it a solved problem. > > So, the challenge Cinder has is the fact that there are many > > configuration options with all the > > different drivers. We had proposed a static cinder/opts.py file with > > hacking checks to ensure > > that all new options were pulled into the file. This was considered > > undesirable. This lead to > > the current solution where we are working to find all the possible > > option lists to dynamically > > create the cinder/opts.py file. Similar to what we used to do with the > > old config generator. > > I proposed, I think, that each driver should have its own entry point, > cinder.foo, cinder.bar, etc. Each entry point refers to a single > function, which can be maintained inside the driver code by the driver > author. Each would then be registered in setup.cfg and listed in the > input file for the config generator. If you also ensure that all of the > options for a given driver are in their own section of the config file, > you'll have a nice neat sample with all of the options. If a deployer or > distributor wants to generate a file that only includes the driver in > use, that's possible by passing different inputs to the config > generator. > > > > > For Nova, having a dynamic solution is less important as they don't have > > options changing > > as frequently. It appears that Neutron was less concerned about the > > potentially dynamic nature > > of options in their drivers. > > > > > For reference: > > > Nova: https://github.com/openstack/nova/blob/master/tox.ini#L90 > > > Neutron: https://github.com/openstack/neutron/blob/master/tox.ini#L198 > > > which calls > > > > https://github.com/openstack/neutron/blob/master/tools/generate_config_file_samples.sh#L17 > > > > Keystone: > https://github.com/openstack/keystone/blob/master/tox.ini#L148 > > > Etc... > > > > > >> I thought it > > >> might be interesting to get a panel together to talk about how it is > > >> done for each project, why it is done that way for each project, and > > >> maybe discuss a more universal approach that could be implemented in > > >> oslo and used by all the projects. Please let me know if you have > > >> knowledge on your project’s method and are interested in being part of > a > > >> panel. > > >> > > >> > > >> If you are interested in looking at Cinder’s approach, here is the > patch > > >> I implemented to make the generation of the sample config file > dynamic: > > >> https://review.openstack.org/#/c/219700/ > > >> > > >> > > >> All the Best, > > >> > > >> *Kendall J. Nelson* > > >> Software Engineer & > > >> > > >> Openstack Cinder Contributor > > >> > ------------------------------------------------------------------------ > > >> *E-mail:*_kjnel...@us.ibm.com_ <mailto:zah...@us.ibm.com> > > >> *Cell Phone:*(952) 215- 4025* > > >> IRC Nickname:*diablo_rojo > > >> IBM > > >> > > >> 3605 Hwy 52 N > > >> Rochester, MN 55901-1407 > > >> United States > > >> > > >> > > >> > > >> > > >> > > >> > __________________________________________________________________________ > > >> OpenStack Development Mailing List (not for usage questions) > > >> Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > >> > > > > > > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
