Open Stack

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
of configs.

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.

	-Sean


> 
> 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
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


-- 
Sean Dague
http://dague.net