[openstack-dev] [all] Austin Summit Panel on Generation of Sample Configuration Option Files
Kendall J Nelson
kjnelson at us.ibm.com
Wed Jan 6 19:27:14 UTC 2016
Yeah something like that- I'm new to the process so I may have the
terminology wrong. So far I have Martin Hickey and Matt Kassawara and
myself. I was hoping to get someone from Nova and maybe someone from
Keystone as well.
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:22 PM
Subject: Re: [openstack-dev] [all] Austin Summit Panel on Generation of
Sample Configuration Option Files
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
> > >>
> > >
> > >
__________________________________________________________________________
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/20160106/9cd8c67d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0A617134.gif
Type: image/gif
Size: 2022 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160106/9cd8c67d/attachment.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/20160106/9cd8c67d/attachment-0001.gif>
More information about the OpenStack-dev
mailing list
