I also find this issue really really annoying. Not only is the sample config a useful reference, but having it in a git repo allows me to see when new options were added or defaults were changed. Otherwise you have to rely on the docs which are generally wrong. When I was looking at some of the Juno transitions, I’ve already filed a few doc bugs about wrong defaults and config options. Assuming a project enforces that the sample config is up-to-date when commits are made, it’s by far the best source of this info. As for why? Well I’ve brought this up a few times before, and there was even a bug filed (https://bugs.launchpad.net/nova/+bug/1301519) but it was marked as “Won’t Fix”. I don’t really know the reason. This is one of my larger annoyances as an operator…
I do know that some projects, like nova and cinder, still ship the file. Maybe someone can setup a cron job to do a pull, build the sample configs and post them to git hub every day. From: "Kris G. Lindgren" <klindg...@godaddy.com<mailto:klindg...@godaddy.com>> Date: Monday, December 8, 2014 at 7:46 PM To: "openstack-operators@lists.openstack.org<mailto:openstack-operators@lists.openstack.org>" <openstack-operators@lists.openstack.org<mailto:openstack-operators@lists.openstack.org>> Subject: [Openstack-operators] Packaging sample config versions Hello all, Since somewhere around icehouse projects have started to stop shipping sample configuration files with their projects and instead create a README-sample.conf.txt that usually contains something like: To generate the sample nova.conf file, run the following command from the top level of the nova directory: tox –egenconfig The problem that I am running into is that tox –egenconfig now requires a newer version of tox than what is available for the build distro: [root@localhost ceilometer-2014.2.1]# tox -egenconfig ERROR: tox version is 1.4.2, required is at least 1.6 I know I can do a pip install blah and blindly hope that I get everything installed locally on my build system and that I don’t install something that conflicts with the system… but that seems like a less than desirable solution. So how are people who are doing packaging handling this? Are you now building a venv per package for tox just to generate a sample configuration? Shouldn't this be part of the python build/install steps per project? It seems redhat/rdo is simply including a sample configuration that they generated somehow. What are you other packagers doing? Also, is it just me or does this seem wrong? Most of the commits that made this change seem to indicate it was because the sample config file was separate from the project and that it was breaking gate when it wasn't kept up to date. Shouldn't this be something that each project generates? This seemed to work for 8 previous releases – now its too difficult? I don’t get the motivations behind this change. ____________________________________________ Kris Lindgren Senior Linux Systems Engineer GoDaddy, LLC. ________________________________ 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 OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
