Open Stack

Hi John,

Let me say first off that I 100% agree with the value of the sample config being in-tree. Keystone has not removed it due to similar feedback I’ve received. However, the issue is that *gating* on config changes for all libraries that are included in the sample config is just a process that leads to this frustration / breakage. I have thought about this, and I think the right answer is two fold:

1) immediately stop gating on sample config changes. I know the cinder team uses it as a “did we break some compat” and “are you changing config” in a patch that could adversely affect deployers/other systems. I don’t think you’re going to win the “don’t change config values in libraries we don’t control” (or even controlled by a separate project) argument. It’s very hard to release an updated oslo lib, clients, or keystonemiddleware.

2) Implement a check (I think I have a way of doing this, I’ll run it by Doug Hellman and you on IRC) that is programatically checking *only* for in-tree config values.

Alternative: A non-voting gate job that says “config has changed” [should be *really* easy to add] so at least you know the config has changed.

This should likely be something easy to get through the door (either the programatic one or the simple non-voting job). This however, needs the infra team buy-in as acceptable.

I know that most projects have moved away from gating on this since we now consume a lot of libraries that provide config options that the individual server-projects don’t control (it is the reason Keystone doesn’t gate explicitly on this).

Just my quick $0.002 on the topic,
—Morgan

> On Dec 3, 2014, at 12:44 PM, John Griffith <john.griffith8 at gmail.com> wrote:
> 
> Hey,
> 
> So this is a long running topic, but I want to bring it up again.
> First, YES Cinder is still running a sample.conf.  A lot of Operators
> spoke up and provided feedback that this was valuable and they
> objected strongly to taking it away.  That being said we're going to
> go the route of removing it from our unit tests and
> generating/publishing periodically outside of tests.
> 
> That being said, one of the things that's driving me crazy and
> breaking things on a regular basis is other OpenStack libs having a
> high rate of change of config options.  This revolves around things
> like fixing typos in the comments, reformatting of text etc.  All of
> these things are good in the long run, but I wonder if we could
> consider batching these sorts of efforts and communicating them?
> 
> The other issue that we hit today was a flat out removal of an option
> in the oslo.messaging lib with no deprecation.  This patch here [1]
> does a number of things that are probably great in terms of clean up
> and housekeeping, but now that we're all in on shared/common libs I
> think we should be a bit more careful about the changes we make.  Also
> to me the commit message doesn't really make it easy for me to search
> git logs to try and figure out what happened when things blew up.
> 
> Anyway, just wanted to send a note out asking people to keep in mind
> the impact of conf changes, and a gentle reminder about depreciation
> periods for the removal of options.
> 
> [1]: https://github.com/openstack/oslo.messaging/commit/bcb3b23b8f6e7d01e38fdc031982558711bb7586
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev