Open Stack

Right, if there are changes needed in oslo-config-generator to make it
work better for cinder then we should just go the next step and
propose a spec as well. There's no need to wait for summit. We should
try to get to consensus and nail this thing really soon.

Thanks,
Dims

On Thu, Jan 7, 2016 at 9:55 AM, Doug Hellmann <doug at doughellmann.com> wrote:
> Excerpts from Kendall J Nelson's message of 2016-01-06 13:27:14 -0600:
>> 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.
>
> OK. The summits are split between normal conference
> presentation-in-front-of-an-audience style tracks (including things
> like panel discussions) and "design session" tracks which are
> discussions among contributors. What you're proposing would fit
> better into a design session, where we could have a conversation
> with our goal being something like plans for better documentation
> for using the config generator based on some agreed best practices.
> I would participate in a discussion like that, if my schedule at
> the summit permits me to.
>
> On the other hand, so far I'm only hearing that Cinder has requirements
> that are not being met by the tool, so I will repeat my request
> that you document them in more detail somehow (this email thread
> would be a good start) so we can all understand the needs. It's
> entirely possible we can resolve this issue before the summit.
>
> 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: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



-- 
Davanum Srinivas :: https://twitter.com/dims