Open Stack

> On Dec 3, 2014, at 1:18 PM, Sean Dague <sean at dague.net> wrote:
> 
> 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.
> 

This is actually what Keystone does. But last time I talked to John they used it for review of config changes purposes. I’m happy to be corrected and I’m a big advocate of “it’s part of the release checklist”.

—Morgan

> 	-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 <mailto:OpenStack-dev at lists.openstack.org>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>> 
> 
> 
> -- 
> Sean Dague
> http://dague.net <http://dague.net/>
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org <mailto:OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141203/dd566dd2/attachment.html>