[Openstack-operators] Packaging sample config versions

Thomas Goirand zigo at debian.org
Wed Jan 28 23:28:11 UTC 2015

On 01/27/2015 11:00 PM, Tom Fifield wrote:
> Hi all,
> Based on Gustavo's excellent work below, talking with many ops, and
> after a brief chats with Jeremey and a few other TC folks, here's what
> I'd propose as an end goal:
> * A git repository that has raw, sample configs in it for each project
> that will be automagically updated
> * Raw configs distributed in the tar files we make as part of the release
> Does that seem acceptable for us all?

It is not. Since it has been already discuss, but we're still not having
any counter point of argumentation, I shall repeat myself, until sanity
gets restored.

You are still *not* addressing the main issue: the .sample config files
*must* match your environment and the version of the different libs on
which a given service is going to run. Therefore, any attempt to go back
to the previous situation (where we have already pre-built config files)
can be considered a grave regression.

Shall I remind everyone that if there's a config option that shouldn't
be there, the daemons will refuse to start?

I don't see what the problem is, really. We have a perfectly valid
system using oslo-config-generator. Here's an example from Ceilometer
Kilo beta 1, in my debian/rules file, in the override_dh_install target:

oslo-config-generator --output-file
                --namespace ceilometer \
                --namespace oslo.db \
                --namespace oslo.messaging \
                --namespace keystonemiddleware.auth_token

This works perfectly, and is very easy to implement on anyone doing
packaging decently.

Now, let's say there's a new version of oslo.db that adds a new
configuration option, but Debian didn't upgrade oslo.db yet. Then the
ceilometer.conf there available online will be *WRONG*.

Please, just don't do it, and force everyone to use
oslo-config-generator, as they should. What's bad is to use stuff from
<project>/openstack/common (ie: oslo-incubator, like it can be seen in
the heat for Kilo beta 1), and that's the thing we shall try to kill
before the final version of Kilo is out.


Thomas Goirand (zigo)

More information about the OpenStack-operators mailing list