Fischer, Matt wrote:
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
<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.
Cinder I believe just kicked that out (for better or worse),
https://github.com/openstack/cinder/commit/62a72a7574b18f7
One less. I don't think nova does either anymore...
Personally I don't know how to solve this without changes around the
usage of oslo.config and its pervasiveness (and how usage of oslo.config
by libraries can alter the valid configuration of a project just by
installing a different library version); which is a pretty big change
all over the place.
Perhaps this goes back to the point that I've seen on the developers
list in:
http://lists.openstack.org/pipermail/openstack-dev/2014-December/052150.html
(perhaps projects shouldn't use libraries that use oslo.config and those
projects should *only* use oslo.config in there top-level project and
configure libraries via some other mechanism that doesn't cause these
kinds of dynamically changing configuration issues).
Something to think about...
-Josh
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
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
