[openstack-dev] [all] Austin Summit Panel on Generation of Sample Configuration Option Files

Doug Hellmann doug at doughellmann.com
Tue Jan 5 15:39:08 UTC 2016


Excerpts from Ben Nemec's message of 2016-01-04 17:43:20 -0600:
> 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.
> 
> 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.

My memory of the discussion was that the Cinder team objected to
maintaining an entry point to be inspected by the config generator.
Unfortunately, because we now have options defined in many libraries, we
can't rely on grep as a global strategy. It worked for incubated Oslo
code, but won't for libraries.

There are a number of issues with the current implementation in cinder:

1. It looks like the patch referenced in the original email is
   dynamically generating a python module to serve as the entry
   point. Unless that file is included in the resulting sdist, it's
   going to make it impossible for a deployer to generate their own
   sample config file, which is something we need to support to
   address changes to config options in libraries upgraded independently
   of the services.

2. The current implementation also doesn't appear to support
   generating different configuration files for different cinder
   services because there is only one "cinder" entry point under
   oslo.config.opts. I see 10 entries under console_scripts, maybe
   8 of which appear to be actual services. Do they all use exactly
   the same options? If not, and you do want to support different
   sample config files for each, then it would be better to register
   multiple names (mirroring the console script names would make
   sense) to provide different inputs to the config generator.
   Projects aren't required to do that, but it was one of the design
   requirements for updating the config generator when we moved it
   out of the incubator into oslo.config.

3. And, a I pointed out in my earlier response, cinder's setup.cfg
   is registering entry points for code it doesn't own, which aside
   from being redundant means config file generation will break if
   those APIs change in the other libraries. The whole reason for
   entry points is to avoid that sort of tight coupling.

It would be good to understand what requirements the cinder team
has that have led to the current implementation so we can work
together to figure out how to accommodate those needs to fix what's
there now.

Doug

> 
> 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:*_kjnelson at us.ibm.com_ <mailto:zahill at 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-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > 
> 



More information about the OpenStack-dev mailing list