Matt, I completely agree.
Nova stopped shipping the file starting in icehouse, ceilometer started in Juno, I see commits now in pretty much every project that remove the sample config and replace it with some tox script. Which may or may not run on your current operating system – without going to pip to get newer versions of stuff. I see that whats being said is that a valid sample configuration file depends on the version of the other dependent libraries that are installed on the system as well. I assume this is talking about different versions of oslo.config and oslo.messaging take different configuration options and as such we can't generate a generic sample config file because we don’t know what versions of dependent libraries you actually have installed. This seems to have taken a problem that’s been created on the development side and simply punted over the wall to let document writers/operators/packagers deal with: As this sample configuration file changes independently from the project, this check failed on the gate time to time, as this file needed to be updated manually [1]. I guess I reject the assertion that the sample configuration file is independent of the project. Just because some options change depending on the oslo.config version doesn't mean the configuration options that are specific to that project change as well… Anyway – back to packaging. The problem that I have with this change is that in order to package a sample configuration I need to basically do the following: 1.) get the current build/commit run 2.) run python build 3.) strip away the relevant built parts of the package 4.) install on the build machine all the python runtime deps that I am going to need for this package 5.) install tox and other packages as needed to generate a sample configuration 6.) generate sample config 7.) build a new package with the exact same requirements as what I installed in step 4 8.) add sample configuration generated in step 6 to the package. Then I need to make sure I also package all of the python-versions that was used in step 4, making sure that I don’t have conflicting system level dependencies from other openstack projects. Now anvil can do a lot of this for me… but this seems overly complicated. 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. IMHO, its also ok if the sample configuration is not 100% perfect re: config options for dependencies – call that out in the config file and we can look up what the correct config parameters are based upon our configuration environment. But there is no execuse to not include an example config that at least has the config options relevant to project. ____________________________________________ Kris Lindgren Senior Linux Systems Engineer GoDaddy, LLC. From: <Fischer>, Matt <matthew.fisc...@twcable.com<mailto:matthew.fisc...@twcable.com>> Date: Monday, December 8, 2014 at 8:23 PM To: "Kris G. Lindgren" <klindg...@godaddy.com<mailto:klindg...@godaddy.com>>, "openstack-operators@lists.openstack.org<mailto:openstack-operators@lists.openstack.org>" <openstack-operators@lists.openstack.org<mailto:openstack-operators@lists.openstack.org>> Subject: Re: [Openstack-operators] Packaging sample config versions 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
