<html><body><p>Hey Doug, <br><br>To respond to your points :)<br><br>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. <br><br>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. <br><br>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. <br><br>All the Best, <br><br>
<table border="0" cellspacing="0" cellpadding="0"><tr valign="top"><td width="433" valign="bottom"><b><font size="4" color="#888888" face="Arial">Kendall J. Nelson</font></b><font size="2" face="Arial"><br>Software Engineer &</font></td></tr></table><font size="2" face="Arial"> Openstack Cinder Contributor</font><table border="0" cellspacing="0" cellpadding="0"><tr valign="top"><td width="433" colspan="2" valign="middle"><hr width="100%" size="2" align="left"></td></tr>
<tr valign="top"><td width="266"><b><font size="1" color="#466BB0" face="Arial">E-mail:</font></b><font size="1" color="#5F5F5F" face="Arial"> </font><a href="mailto:zahill@us.ibm.com" target="_blank"><u><font size="1" color="#5F5F5F" face="Arial">kjnelson@us.ibm.com</font></u></a><br><b><font size="1" color="#466BB0" face="Arial">Cell Phone:</font></b><font size="1" color="#5F5F5F" face="Arial"> (952) 215- 4025</font><b><font size="1" color="#466BB0" face="Arial"><br>IRC Nickname:</font></b><font size="1" color="#5F5F5F" face="Arial"> diablo_rojo</font></td><td width="167"><div align="right"><img src="cid:1__=8FBBF5A2DFFF5A948f9e8a93df938690918c8FB@" width="55" height="20" alt="IBM"><font size="1" color="#5F5F5F" face="Arial"><br><br>3605 Hwy 52 N<br>Rochester, MN 55901-1407<br>United States</font></div></td></tr></table><br><br><img width="16" height="16" src="cid:2__=8FBBF5A2DFFF5A948f9e8a93df938690918c8FB@" border="0" alt="Inactive hide details for Doug Hellmann ---01/05/2016 09:45:11 AM---Excerpts from Ben Nemec's message of 2016-01-04 17:43:20 -0"><font color="#424282">Doug Hellmann ---01/05/2016 09:45:11 AM---Excerpts from Ben Nemec's message of 2016-01-04 17:43:20 -0600: > On 01/04/2016 03:50 PM, Kendall J</font><br><br><font size="2" color="#5F5F5F">From: </font><font size="2">Doug Hellmann <doug@doughellmann.com></font><br><font size="2" color="#5F5F5F">To: </font><font size="2">openstack-dev <openstack-dev@lists.openstack.org></font><br><font size="2" color="#5F5F5F">Date: </font><font size="2">01/05/2016 09:45 AM</font><br><font size="2" color="#5F5F5F">Subject: </font><font size="2">Re: [openstack-dev] [all] Austin Summit Panel on Generation of Sample Configuration Option Files</font><br><hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br><br><br><tt>Excerpts from Ben Nemec's message of 2016-01-04 17:43:20 -0600:<br>> On 01/04/2016 03:50 PM, Kendall J Nelson wrote:<br>> > Hello,<br>> > <br>> > <br>> > In brainstorming ideas for talks at the upcoming summit, I thought about<br>> > some of the things I had worked on for Cinder and what could still be<br>> > improved. One of the things I have been looking into is the generation<br>> > of sample configuration option files. Upon initial research it looks<br>> > like none of the main projects are doing it the same way. <br>> <br>> I'm not sure what you mean. Nova, Neutron, Keystone, Glance, and Heat<br>> (at least) are all using the oslo-config-generator tool for this. There<br>> might be some slight variation in how they call it, but they are using it.<br>> <br>> I only vaguely recall having discussions about this with Cinder, so I'd<br>> be interested in a refresher around why Cinder didn't want to do it the<br>> same way. I kind of considered it a solved problem.<br><br>My memory of the discussion was that the Cinder team objected to<br>maintaining an entry point to be inspected by the config generator.<br>Unfortunately, because we now have options defined in many libraries, we<br>can't rely on grep as a global strategy. It worked for incubated Oslo<br>code, but won't for libraries.<br><br>There are a number of issues with the current implementation in cinder:<br><br>1. It looks like the patch referenced in the original email is<br> dynamically generating a python module to serve as the entry<br> point. Unless that file is included in the resulting sdist, it's<br> going to make it impossible for a deployer to generate their own<br> sample config file, which is something we need to support to<br> address changes to config options in libraries upgraded independently<br> of the services.<br><br>2. The current implementation also doesn't appear to support<br> generating different configuration files for different cinder<br> services because there is only one "cinder" entry point under<br> oslo.config.opts. I see 10 entries under console_scripts, maybe<br> 8 of which appear to be actual services. Do they all use exactly<br> the same options? If not, and you do want to support different<br> sample config files for each, then it would be better to register<br> multiple names (mirroring the console script names would make<br> sense) to provide different inputs to the config generator.<br> Projects aren't required to do that, but it was one of the design<br> requirements for updating the config generator when we moved it<br> out of the incubator into oslo.config.<br><br>3. And, a I pointed out in my earlier response, cinder's setup.cfg<br> is registering entry points for code it doesn't own, which aside<br> from being redundant means config file generation will break if<br> those APIs change in the other libraries. The whole reason for<br> entry points is to avoid that sort of tight coupling.<br><br>It would be good to understand what requirements the cinder team<br>has that have led to the current implementation so we can work<br>together to figure out how to accommodate those needs to fix what's<br>there now.<br><br>Doug<br><br>> <br>> For reference:<br>> Nova: </tt><tt><a href="https://github.com/openstack/nova/blob/master/tox.ini#L90">https://github.com/openstack/nova/blob/master/tox.ini#L90</a></tt><tt><br>> Neutron: </tt><tt><a href="https://github.com/openstack/neutron/blob/master/tox.ini#L198">https://github.com/openstack/neutron/blob/master/tox.ini#L198</a></tt><tt><br>> which calls<br>> </tt><tt><a href="https://github.com/openstack/neutron/blob/master/tools/generate_config_file_samples.sh#L17">https://github.com/openstack/neutron/blob/master/tools/generate_config_file_samples.sh#L17</a></tt><tt><br>> Keystone: </tt><tt><a href="https://github.com/openstack/keystone/blob/master/tox.ini#L148">https://github.com/openstack/keystone/blob/master/tox.ini#L148</a></tt><tt><br>> Etc...<br>> <br>> > I thought it<br>> > might be interesting to get a panel together to talk about how it is<br>> > done for each project, why it is done that way for each project, and<br>> > maybe discuss a more universal approach that could be implemented in<br>> > oslo and used by all the projects. Please let me know if you have<br>> > knowledge on your project’s method and are interested in being part of a<br>> > panel.<br>> > <br>> > <br>> > If you are interested in looking at Cinder’s approach, here is the patch<br>> > I implemented to make the generation of the sample config file dynamic:<br>> > </tt><tt><a href="https://review.openstack.org/#/c/219700/">https://review.openstack.org/#/c/219700/</a></tt><tt><br>> > <br>> > <br>> > All the Best,<br>> > <br>> > *Kendall J. Nelson*<br>> > Software Engineer &<br>> > <br>> > Openstack Cinder Contributor<br>> > ------------------------------------------------------------------------<br>> > *E-mail:*_kjnelson@us.ibm.com_ <</tt><tt><a href="mailto:zahill@us.ibm.com">mailto:zahill@us.ibm.com</a></tt><tt>><br>> > *Cell Phone:*(952) 215- 4025*<br>> > IRC Nickname:*diablo_rojo <br>> > IBM<br>> > <br>> > 3605 Hwy 52 N<br>> > Rochester, MN 55901-1407<br>> > United States<br>> > <br>> > <br>> > <br>> > <br>> > <br>> > __________________________________________________________________________<br>> > OpenStack Development Mailing List (not for usage questions)<br>> > Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>> > </tt><tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></tt><tt><br>> > <br>> <br><br>__________________________________________________________________________<br>OpenStack Development Mailing List (not for usage questions)<br>Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br></tt><tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></tt><tt><br></tt><br><BR>
</body></html>