[Openstack-operators] Packaging sample config versions

Joshua Harlow harlowja at outlook.com
Tue Dec 9 03:35:46 UTC 2014


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" <klindgren at godaddy.com
> <mailto:klindgren at godaddy.com>>
> Date: Monday, December 8, 2014 at 7:46 PM
> To: "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: [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 at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators



More information about the OpenStack-operators mailing list