Open Stack

Excerpts from Kendall J Nelson's message of 2016-01-05 13:52:10 -0600:
> Hey Doug,
> 
> To respond to your points :)
> 
> 1. We are actually including the resulting opts.py file from
> generate_cinder_opts.py so that deployers can distribute. That was added in
> a subsequent patch- sorry for that confusion.

Great, that wasn't clear based on looking at that one patch but if
you're shipping the file in the sdist that does address one of my
concerns.

> 
> 2. As for support for generating different configuration files for
> different cinder services, we haven't faced that request yet. It could be
> something to look into though since it could very well be a requirement in
> the future though.

Yes, it's something to keep in mind. It was an important feature of the
new config generator, but not all projects are using it, yet.

> 
> 3. To your third point, I now see the flaw in how we are getting options
> from keystone. Not entirely sure how to handle getting them though. Can you
> elaborate on a better approach? I briefly looked into the nova setup.cfg,
> but couldn't find any references to keystone.

You don't need to mention keystone in your setup.cfg at all. The
config generator uses a config file to tell it which entry points
it should query for options. It looks like for cinder that file is
cinder/config/cinder-config-generator.conf. The "namespace" entries
there refer to the plugin names to be loaded. If you ensure that
all of the entry points for dependencies of cinder are listed there,
you'll get all of the options in your sample config.

Some dependencies may have multiple entry points. oslo.middleware
is a good example of this. It has oslo.middleware, oslo.middleware.cors,
oslo.middleware.sizelimit, and oslo.middleware.ssl. You should include
the entry points for the middleware you rely on. Check the documentation
for other libraries to see if they have similar cases. If you don't find
info about config generator entry points in the docs for a library,
please file a bug for the project so we can update them.

Using the config generator is described in the docs at
http://docs.openstack.org/developer/oslo.config/generator.html but
I can see maybe that's not clear (and detailed) enough, so I'll put
an item on my todo list to work on those instructions, unless another
Oslo team member beats me to it.

Doug


> 
> All the Best,
>                                                           
>    Kendall J. Nelson                                      
>    Software Engineer &                                    
>                                                           
> 
> 
>     Openstack Cinder Contributor
>                                                            
>                                                            
>                                                            
>    E-mail: kjnelson at 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 <doug at doughellmann.com>
> To:    openstack-dev <openstack-dev at lists.openstack.org>
> Date:    01/05/2016 09:45 AM
> Subject:    Re: [openstack-dev] [all] Austin Summit Panel on Generation of
>             Sample Configuration Option Files
> 
> 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
> > >
> > >
> > >
> > >
> > >
> > >