[openstack-dev] [OpenStack-Dev] Config Options and OSLO libs
sean at dague.net
Wed Dec 3 21:18:41 UTC 2014
On 12/03/2014 03:58 PM, Morgan Fainberg wrote:
> 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).
So I think there is a better way. The end game here is you want an up to
date sample config in your tree.
Ok, so as a post merge figure out if you need a config change, and if so
proposal bot that back in. Better yet, publish these somewhere on the
web so people can browse samples. Maybe even for a few different kinds
Make it part of the release checklist for a milestone that the tool
which generates the config is run manually and make sure that the in
tree config is up to date. Which might mean in master it's behind a bit,
but at least it will be right for any releases.
> Just my quick $0.002 on the topic,
>> On Dec 3, 2014, at 12:44 PM, John Griffith <john.griffith8 at gmail.com> wrote:
>> 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 
>> 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.
>> : https://github.com/openstack/oslo.messaging/commit/bcb3b23b8f6e7d01e38fdc031982558711bb7586
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
More information about the OpenStack-dev