Open Stack

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.

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.

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.

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
> >
> >
> >
> >
> >
> >
__________________________________________________________________________
> > 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
> >
>

__________________________________________________________________________
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160105/3b6fb069/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 5A069843.gif
Type: image/gif
Size: 2022 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160105/3b6fb069/attachment-0002.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160105/3b6fb069/attachment-0003.gif>