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 <[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] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
