On Wed, Dec 10, 2014 at 11:16 AM, Fischer, Matt <[email protected] > wrote:
> > > From: Anne Gentle <[email protected]> > Date: Wednesday, December 10, 2014 at 8:41 AM > To: Michael Dorman <[email protected]> > Cc: "[email protected]" < > [email protected]> > Subject: Re: [Openstack-operators] Packaging sample config versions > > > > On Tue, Dec 9, 2014 at 11:25 AM, Michael Dorman <[email protected]> > 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" <[email protected]> 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@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é" <[email protected]> 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 >> >[email protected] >> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >> _______________________________________________ >> OpenStack-operators mailing list >> [email protected] >> 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. >
_______________________________________________ OpenStack-operators mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
