<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;"><div>Top-posting because the quoting is getting pretty deep:</div><div><br></div><div><div>>At first glance, I don't know what's going on there, so I'll investigate further and comment in the bugs. Thanks Matt for logging. </div><div>></div><div>>I'm not sure I exactly understand the difference between sample configs and example configs - my best guess is:</div><div>>sample configs: complete .conf file with some options enabled that will work and all the rest of the options in the file but commented out including defaults and description?</div><div>>example configs: working .conf file that doesn't contain all the options.</div><div>></div><div>>Is that accurate?</div></div><div><br></div><div>Yes, that’s right. I see example configs as useful for something like “how do I configure keystone to talk to LDAP”, whereas sample configs (aka complete configs) are useful for me when I want to know whether puppet is changing a default. I’d say we inherit 75% or more default values, and my “upstream” for defaults is not only the projects but the puppet code.</div><div><br></div><div>If you have better terminology, I’m happy to switch, sorry for the potential confusion.</div><div><br></div><div>Thanks.</div><div><br></div><div><br></div><span id="OLK_SRC_BODY_SECTION"><div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt"><span style="font-weight:bold">From: </span> Anne Gentle <<a href="mailto:anne@openstack.org">anne@openstack.org</a>><br><span style="font-weight:bold">Date: </span> Thursday, December 11, 2014 at 9:38 AM<br><span style="font-weight:bold">To: </span> Matt Fischer <<a href="mailto:matthew.fischer@twcable.com">matthew.fischer@twcable.com</a>><br><span style="font-weight:bold">Cc: </span> Michael Dorman <<a href="mailto:mdorman@godaddy.com">mdorman@godaddy.com</a>>, "<a href="mailto:openstack-operators@lists.openstack.org">openstack-operators@lists.openstack.org</a>" <<a href="mailto:openstack-operators@lists.openstack.org">openstack-operators@lists.openstack.org</a>><br><span style="font-weight:bold">Subject: </span> Re: [Openstack-operators] Packaging sample config versions<br></div><div><br></div><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 10, 2014 at 11:16 AM, Fischer, Matt <span dir="ltr"><<a href="mailto:matthew.fischer@twcable.com" target="_blank">matthew.fischer@twcable.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div style="color:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:14px"><br></div><div style="color:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:14px"><br></div><span style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 14px;"><div style="font-family:Calibri;font-size:11pt;text-align:left;color:black;BORDER-BOTTOM:medium none;BORDER-LEFT:medium none;PADDING-BOTTOM:0in;PADDING-LEFT:0in;PADDING-RIGHT:0in;BORDER-TOP:#b5c4df 1pt solid;BORDER-RIGHT:medium none;PADDING-TOP:3pt"><span style="font-weight:bold">From: </span>Anne Gentle <<a href="mailto:anne@openstack.org" target="_blank">anne@openstack.org</a>><br><span style="font-weight:bold">Date: </span>Wednesday, December 10, 2014 at 8:41 AM<br><span style="font-weight:bold">To: </span>Michael Dorman <<a href="mailto:mdorman@godaddy.com" target="_blank">mdorman@godaddy.com</a>><br><span style="font-weight:bold">Cc: </span>"<a href="mailto:openstack-operators@lists.openstack.org" target="_blank">openstack-operators@lists.openstack.org</a>" <<a href="mailto:openstack-operators@lists.openstack.org" target="_blank">openstack-operators@lists.openstack.org</a>><span class=""><br><span style="font-weight:bold">Subject: </span>Re: [Openstack-operators] Packaging sample config versions<br></span></div><div><br></div><div dir="ltr"><br><span class=""><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 9, 2014 at 11:25 AM, Michael Dorman <span dir="ltr">
<<a href="mailto:mdorman@godaddy.com" target="_blank">mdorman@godaddy.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Well I think we can all agree this is an irritation. But how are others<br>
actually dealing with this problem? (Maybe it’s less complicated in<br>
Ubuntu.)<br><br>
The sense I get is that most people using Anvil, or other custom-ish<br>
packaging tools, are also running config management which handles<br>
generating the config files, anyway. So you don’t so much care about the<br>
contents of the config file shipped with the package.<br><br>
Is that accurate for most people? Or are folks doing some other magic to<br>
get a good config file in the packages?<br></blockquote><div><br></div><div>>The docs team -- reallly, Matt Kassawara -- regularly logs bugs for packagers to put in better, working, default config files. </div><div>></div><div>>We do generate documentation for all the configurations across projects that use oslo.config (and even for swift, which doesn't). So you can rely on this reference:</div><div>><a href="http://docs.openstack.org/juno/config-reference/content/" target="_blank">http://docs.openstack.org/juno/config-reference/content/</a></div></div></div></span></div></span><div style="color:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:14px"><br></div><div style="color:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:14px">
I don’t see full sample configs in here, just more focused “example” configs, am I missing it? Does the generated content include everything from config.py in each project? I’m asking because I’ve seen a few places where the documented defaults and whats in
the code do not match.</div><div style="color:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:14px"><br></div><div style="color:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:14px">
When I upgrade puppet versions, like I’m doing now from the icehouse puppet branches, its very important for me to know:</div><ol style="color:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:14px"><li>what has a new default value</li><li>whether we were previously using the old default value</li><li>what lines change/move/got renamed</li><li>what is deprecated</li></ol><div style="color:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:14px">
The docs do a good job of most of these, but I cannot beat a well maintained full sample config. </div><div style="color:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:14px"><br></div><div style="color:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:14px">
Here are a few small examples of places where the docs and code didn’t match for Juno, hence my questions about how the docs were generated:</div><div style="color:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:14px"><br></div><div style="color:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:14px"><a href="https://bugs.launchpad.net/openstack-manuals/+bug/1380778" target="_blank">https://bugs.launchpad.net/openstack-manuals/+bug/1380778</a></div><div style="color:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:14px"><a href="https://bugs.launchpad.net/openstack-manuals/+bug/1380813" target="_blank">https://bugs.launchpad.net/openstack-manuals/+bug/1380813</a></div><div style="color:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:14px"><br></div></div></blockquote><div><br></div><div>At first glance, I don't know what's going on there, so I'll investigate further and comment in the bugs. Thanks Matt for logging. </div><div><br></div><div>I'm not sure I exactly understand the difference between sample configs and example configs - my best guess is:</div><div>sample configs: complete .conf file with some options enabled that will work and all the rest of the options in the file but commented out including defaults and description?</div><div>example configs: working .conf file that doesn't contain all the options.</div><div><br></div><div>Is that accurate?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div style="color:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:14px"></div><div>Note: I also filed two bugs against keystone itself for having default values that were deprecated, so its not perfect either.</div><div><div class="h5"><span style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 14px;"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>>You can also see new, updated, and deprecated options for each service, such as:</div><div>><a href="http://docs.openstack.org/juno/config-reference/content/nova-conf-changes-juno.html" target="_blank">http://docs.openstack.org/juno/config-reference/content/nova-conf-changes-juno.html</a><br></div><div>></div><div>>I don't believe our reference document was what encouraged devs to take the sample config generation out-of-tree, but I am letting you know your best option besides troubleshooting generating it yourself.</div><div>></div><div>>Anne</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
Mike<br><div><div><br><br><br><br><br>
On 12/9/14, 5:02 PM, "Kris G. Lindgren" <<a href="mailto:klindgren@godaddy.com" target="_blank">klindgren@godaddy.com</a>> wrote:<br><br>
>So more to my point on the latest version of RHEL and doing: yum install<br>
>tox -egenconfig<br>
><br>
>ceilometer-2014.2.1]# tox -egenconfig<br>
>ERROR: tox version is 1.4.2, required is at least 1.6<br>
><br>
><br>
>nova-2014.2.1]# tox -egenconfig<br>
>ERROR: tox version is 1.4.2, required is at least 1.6<br>
><br>
><br>
>glance-2014.2.1]# tox -egenconfig<br>
>ERROR: tox version is 1.4.2, required is at least 1.6<br>
><br>
><br>
>[root@localhost ~]# pip install --update tox<br>
>(Updated tox to 1.8.1 , upgraded virtualenv to 1.10.1 and upgraded py to<br>
>1.4.14)<br>
><br>
>glance-2014.2.1]# tox -egenconfig<br>
>genconfig create: /root/rpmbuild/BUILD/glance-2014.2.1/.tox/genconfig<br>
>genconfig installdeps:<br>
>-r/root/rpmbuild/BUILD/glance-2014.2.1/requirements.txt,<br>
>-r/root/rpmbuild/BUILD/glance-2014.2.1/test-requirements.txt<br>
>ERROR: invocation failed (exit code 1), logfile:<br>
>/root/rpmbuild/BUILD/glance-2014.2.1/.tox/genconfig/log/genconfig-1.log<br>
>ERROR: actionid=genconfig<br>
><SNIP><br>
><br>
>Running setup.py install for MySQL-python<br>
><SNIP><br>
> /usr/include/mysql/my_config_x86_64.h:654:2: error: #error<br>
><my_config.h> MUST be included first!<br>
> #error <my_config.h> MUST be included first!<br>
> ^<br>
> error: command 'gcc' failed with exit status 1<br>
><snip><br>
>__________________________________________________________________ summary<br>
>__________________________________________________________________<br>
>ERROR: genconfig: could not install deps<br>
>[-r/root/rpmbuild/BUILD/glance-2014.2.1/requirements.txt,<br>
>-r/root/rpmbuild/BUILD/glance-2014.2.1/test-requirements.txt]; v =<br>
>InvocationError('/root/rpmbuild/BUILD/glance-2014.2.1/.tox/genconfig/bin/p<br>
>i<br>
>p install --allow-all-external --allow-insecure netaddr -U<br>
>-r/root/rpmbuild/BUILD/glance-2014.2.1/requirements.txt<br>
>-r/root/rpmbuild/BUILD/glance-2014.2.1/test-requirements.txt (see<br>
>/root/rpmbuild/BUILD/glance-2014.2.1/.tox/genconfig/log/genconfig-1.log)',<br>
>1)<br>
><br>
><br>
><br>
>So a few things to point out in order to even get tox -egenconfig I had to<br>
>update the system packages versions using pip. Since we have other python<br>
>packages using virtualenv I have no idea if the updated venvironment<br>
>package is going to break those systems or not. So the included<br>
>script/command is already a barrier to getting a sample config. 2) tox<br>
>fails to even build all the deps - it happens to be exactly failing at<br>
>mysql in both nova/cinder/glance/keystone 3) It's installing it own<br>
>versions of python libraries that solve the dependencies that are then<br>
>going to be used to generate the configuration. If the configuration is<br>
>so dynamic that getting a different version of oslo.config could generate<br>
>a sample configuration that wont work on my system then how am I suppose<br>
>to deal with:<br>
>Tox installed version:<br>
>oslo.config-1.5.0<br>
><br>
><br>
>System installed version:<br>
>python-oslo-config-1.3.0<br>
><br>
><br>
><br>
><br>
>Also python-libvrit failed to build because I donšt have libvrit installed<br>
>on this system. So am I to assume that there are no libvrit options<br>
>(which we both know is false)?<br>
>Now I can get a example config - that wont work with my system - per what<br>
>everyone else has been saying. Also, at what point would the average user<br>
>just say "F it"? - because at the point I feel like if I was an average<br>
>user - I would be there right now.<br>
>____________________________________________<br>
><br>
>Kris Lindgren<br>
>Senior Linux Systems Engineer<br>
>GoDaddy, LLC.<br>
><br>
><br>
>On 12/9/14, 8:14 AM, "Mathieu Gagné" <<a href="mailto:mgagne@iweb.com" target="_blank">mgagne@iweb.com</a>> wrote:<br>
><br>
>>On 2014-12-08 11:01 PM, Kris G. Lindgren wrote:<br>
>>><br>
>>> I donšt think its too much to ask for each project to include a<br>
>>>script<br>
>>> that will build a venv that includes tox and the other relevant deps to<br>
>>> build the sample configuration.<br>
>><br>
>>This is already the case. Back then, I did the work of documenting how<br>
>>you could generate the sample config files for each projects (I cared<br>
>>about):<br>
>><a href="http://blog.mgagne.ca/generating-sample-config-files-in-openstack/" target="_blank">http://blog.mgagne.ca/generating-sample-config-files-in-openstack/</a><br>
>><br>
>>You can see that the process isn't streamlined. Each project has its own<br>
>>particularities. Some projects don't use the (un)official standard "tox<br>
>>-egenconfig" command, I patched some projects to make it less a pain.<br>
>><br>
>>And my thoughts about sample config files:<br>
>><a href="http://blog.mgagne.ca/where-are-the-sample-config-files/" target="_blank">http://blog.mgagne.ca/where-are-the-sample-config-files/</a><br>
>><br>
>>I wrote it after Cinder proposed removing its sample config file. They<br>
>>abandoned the patch at that time but now sample config file is gone.<br>
>><br>
>>It's not an easy problem because core libraries used by OpenStack<br>
>>projects also use oslo.config and configs required by those libraries<br>
>>are part of the main configurations required for a project to even work.<br>
>>([database]/connection for instance) You just can't ignore those configs<br>
>>when generating the sample config file.<br>
>><br>
>>(sorry for self-promotion, I didn't want to rewrite my thoughts on this<br>
>>list)<br>
>><br>
>>--<br>
>>Mathieu<br>
><br>
><br>
>_______________________________________________<br>
>OpenStack-operators mailing list<br>
><a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.openstack.org</a><br>
><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
_______________________________________________<br>
OpenStack-operators mailing list<br><a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.openstack.org</a><br><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br></div></div></blockquote></div><br></div></div></span><br></div></div><span class=""><hr><font face="Arial" color="Gray" size="1">This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely
for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to
this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.<br></font></span></div></blockquote></div><br></div></div></span></body></html>