[openstack-dev] [all] sample config files should be ignored in git...

Clint Byrum clint at fewbar.com
Wed Mar 26 20:09:52 UTC 2014


Excerpts from Steven Hardy's message of 2014-03-26 11:27:58 -0700:
> On Wed, Mar 26, 2014 at 11:10:04AM -0700, Clint Byrum wrote:
> > This is an issue that affects all of our git repos. If you are using
> > oslo.config, you will likely also be using the sample config generator.
> > 
> > However, for some reason we are all checking this generated file in.
> > This makes no sense, as we humans are not editting it, and it often
> > picks up config files from other things like libraries (keystoneclient
> > in particular). This has lead to breakage in the gate a few times for
> > Heat, perhaps for others as well.
> > 
> > I move that we all rm this file from our git trees, and start generating
> > it as part of the install/dist process (I have no idea how to do
> > this..). This would require:
> > 
> > - rm sample files and add them to .gitignore in all trees
> > - Removing check_uptodate.sh from all trees/tox.ini's
> > - Generating file during dist/install process.
> > 
> > Does anyone disagree?
> 
> So this sounds like a great idea in theory, I'd love to stop getting
> surprise gate breakage every keystoneclient release becuause of minor
> changes to keystone_authtoken.
> 
> My main concern is we're replacing suprise breakage due to keystoneclient
> with surprise breakage due to oslo.config, since that version is not
> capped.
> 
> E.g look at this review I just posted (too hastily) - generate_sample.sh
> has done something crazy and generated a totally broken config:
> 
> https://review.openstack.org/#/c/83151/
> 
> I'm not quite clear on why that's broken, but it does highlight one of the
> problems with relying on autogeneration with no review.  I guess we'll get
> to review the logs of the broken gate tests instead :\
> 
> I'd love to hear ideas on how we can do this in an automated way which
> won't be really unstable/unreliable.

This seems like a real bug, and one that would hopefully be handled
through the normal bug fixing cycle that includes ensuring test
coverage. No?



More information about the OpenStack-dev mailing list