> On Dec 3, 2014, at 1:18 PM, Sean Dague <[email protected]> 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 <[email protected]> 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 >>> [email protected] >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> _______________________________________________ >> OpenStack-dev mailing list >> [email protected] <mailto:[email protected]> >> 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 > [email protected] <mailto:[email protected]> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
