Open Stack

Top-posting because the quoting is getting pretty deep:

>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.
>
>I'm not sure I exactly understand the difference between sample configs and example configs - my best guess is:
>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?
>example configs: working .conf file that doesn't contain all the options.
>
>Is that accurate?

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.

If you have better terminology, I’m happy to switch, sorry for the potential confusion.

Thanks.


From: Anne Gentle <anne at openstack.org<mailto:anne at openstack.org>>
Date: Thursday, December 11, 2014 at 9:38 AM
To: Matt Fischer <matthew.fischer at twcable.com<mailto:matthew.fischer at twcable.com>>
Cc: Michael Dorman <mdorman at godaddy.com<mailto:mdorman at godaddy.com>>, "openstack-operators at lists.openstack.org<mailto:openstack-operators at lists.openstack.org>" <openstack-operators at lists.openstack.org<mailto:openstack-operators at lists.openstack.org>>
Subject: Re: [Openstack-operators] Packaging sample config versions



On Wed, Dec 10, 2014 at 11:16 AM, Fischer, Matt <matthew.fischer at twcable.com<mailto:matthew.fischer at twcable.com>> wrote:


From: Anne Gentle <anne at openstack.org<mailto:anne at openstack.org>>
Date: Wednesday, December 10, 2014 at 8:41 AM
To: Michael Dorman <mdorman at godaddy.com<mailto:mdorman at godaddy.com>>
Cc: "openstack-operators at lists.openstack.org<mailto:openstack-operators at lists.openstack.org>" <openstack-operators at lists.openstack.org<mailto:openstack-operators at lists.openstack.org>>
Subject: Re: [Openstack-operators] Packaging sample config versions



On Tue, Dec 9, 2014 at 11:25 AM, Michael Dorman <mdorman at godaddy.com<mailto:mdorman at godaddy.com>> wrote:
Well I think we can all agree this is an irritation.  But how are others
actually dealing with this problem?  (Maybe it’s less complicated in
Ubuntu.)

The sense I get is that most people using Anvil, or other custom-ish
packaging tools, are also running config management which handles
generating the config files, anyway.  So you don’t so much care about the
contents of the config file shipped with the package.

Is that accurate for most people?  Or are folks doing some other magic to
get a good config file in the packages?

>The docs team -- reallly, Matt Kassawara -- regularly logs bugs for packagers to put in better, working, default config files.
>
>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:
>http://docs.openstack.org/juno/config-reference/content/

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.

When I upgrade puppet versions, like I’m doing now from the icehouse puppet branches, its very important for me to know:

 1.  what has a new default value
 2.  whether we were previously using the old default value
 3.  what lines change/move/got renamed
 4.  what is deprecated

The docs do a good job of most of these, but I cannot beat a well maintained full sample config.

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:

https://bugs.launchpad.net/openstack-manuals/+bug/1380778
https://bugs.launchpad.net/openstack-manuals/+bug/1380813


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.

I'm not sure I exactly understand the difference between sample configs and example configs - my best guess is:
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?
example configs: working .conf file that doesn't contain all the options.

Is that accurate?

Note: I also filed two bugs against keystone itself for having default values that were deprecated, so its not perfect either.

>You can also see new, updated, and deprecated options for each service, such as:
>http://docs.openstack.org/juno/config-reference/content/nova-conf-changes-juno.html
>
>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.
>
>Anne


Mike





On 12/9/14, 5:02 PM, "Kris G. Lindgren" <klindgren at godaddy.com<mailto:klindgren at godaddy.com>> wrote:

>So more to my point on the latest version of RHEL and doing: yum install
>tox -egenconfig
>
>ceilometer-2014.2.1]# tox -egenconfig
>ERROR: tox version is 1.4.2, required is at least 1.6
>
>
>nova-2014.2.1]# tox -egenconfig
>ERROR: tox version is 1.4.2, required is at least 1.6
>
>
>glance-2014.2.1]# tox -egenconfig
>ERROR: tox version is 1.4.2, required is at least 1.6
>
>
>[root at localhost ~]# pip install --update tox
>(Updated tox to 1.8.1 , upgraded virtualenv to 1.10.1 and upgraded py to
>1.4.14)
>
>glance-2014.2.1]# tox -egenconfig
>genconfig create: /root/rpmbuild/BUILD/glance-2014.2.1/.tox/genconfig
>genconfig installdeps:
>-r/root/rpmbuild/BUILD/glance-2014.2.1/requirements.txt,
>-r/root/rpmbuild/BUILD/glance-2014.2.1/test-requirements.txt
>ERROR: invocation failed (exit code 1), logfile:
>/root/rpmbuild/BUILD/glance-2014.2.1/.tox/genconfig/log/genconfig-1.log
>ERROR: actionid=genconfig
><SNIP>
>
>Running setup.py install for MySQL-python
><SNIP>
>   /usr/include/mysql/my_config_x86_64.h:654:2: error: #error
><my_config.h> MUST be included first!
>     #error <my_config.h> MUST be included first!
>      ^
>    error: command 'gcc' failed with exit status 1
><snip>
>__________________________________________________________________ summary
>__________________________________________________________________
>ERROR:   genconfig: could not install deps
>[-r/root/rpmbuild/BUILD/glance-2014.2.1/requirements.txt,
>-r/root/rpmbuild/BUILD/glance-2014.2.1/test-requirements.txt]; v =
>InvocationError('/root/rpmbuild/BUILD/glance-2014.2.1/.tox/genconfig/bin/p
>i
>p install --allow-all-external --allow-insecure netaddr -U
>-r/root/rpmbuild/BUILD/glance-2014.2.1/requirements.txt
>-r/root/rpmbuild/BUILD/glance-2014.2.1/test-requirements.txt (see
>/root/rpmbuild/BUILD/glance-2014.2.1/.tox/genconfig/log/genconfig-1.log)',
>1)
>
>
>
>So a few things to point out in order to even get tox -egenconfig I had to
>update the system packages versions using pip.  Since we have other python
>packages using virtualenv I have no idea if the updated venvironment
>package is going to break those systems or not.  So the included
>script/command is already a barrier to getting a sample config.  2) tox
>fails to even build all the deps - it happens to be exactly failing at
>mysql in both nova/cinder/glance/keystone 3) It's installing it own
>versions of python libraries that solve the dependencies that are then
>going to be used to generate the configuration.  If the configuration is
>so dynamic that getting a different version of oslo.config could generate
>a sample configuration that wont work on my system then how am I suppose
>to deal with:
>Tox installed version:
>oslo.config-1.5.0
>
>
>System installed version:
>python-oslo-config-1.3.0
>
>
>
>
>Also python-libvrit failed to build because I don¹t have libvrit installed
>on this system.  So am I to assume that there are no libvrit options
>(which we both know is false)?
>Now I can get a example config - that wont work with my system - per what
>everyone else has been saying.  Also, at what point would the average user
>just say "F it"? - because at the point I feel like if I was an average
>user - I would be there right now.
>____________________________________________
>
>Kris Lindgren
>Senior Linux Systems Engineer
>GoDaddy, LLC.
>
>
>On 12/9/14, 8:14 AM, "Mathieu Gagné" <mgagne at iweb.com<mailto:mgagne at iweb.com>> wrote:
>
>>On 2014-12-08 11:01 PM, Kris G. Lindgren wrote:
>>>
>>>   I don¹t think its too much to ask for each project to include a
>>>script
>>> that will build a venv that includes tox and the other relevant deps to
>>> build the sample configuration.
>>
>>This is already the case. Back then, I did the work of documenting how
>>you could generate the sample config files for each projects (I cared
>>about):
>>http://blog.mgagne.ca/generating-sample-config-files-in-openstack/
>>
>>You can see that the process isn't streamlined. Each project has its own
>>particularities. Some projects don't use the (un)official standard "tox
>>-egenconfig" command, I patched some projects to make it less a pain.
>>
>>And my thoughts about sample config files:
>>http://blog.mgagne.ca/where-are-the-sample-config-files/
>>
>>I wrote it after Cinder proposed removing its sample config file. They
>>abandoned the patch at that time but now sample config file is gone.
>>
>>It's not an easy problem because core libraries used by OpenStack
>>projects also use oslo.config and configs required by those libraries
>>are part of the main configurations required for a project to even work.
>>([database]/connection for instance) You just can't ignore those configs
>>when generating the sample config file.
>>
>>(sorry for self-promotion, I didn't want to rewrite my thoughts on this
>>list)
>>
>>--
>>Mathieu
>
>
>_______________________________________________
>OpenStack-operators mailing list
>OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


________________________________
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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20141211/39c8de54/attachment.html>