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.
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:*[email protected]_ <mailto:[email protected]>
*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: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
