Open Stack

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: 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/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:*_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
> > >>
> > >
> > >