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

Clint Byrum clint at fewbar.com
Wed Mar 26 20:08:01 UTC 2014

Excerpts from Anne Gentle's message of 2014-03-26 11:49:29 -0700:
> On Wed, Mar 26, 2014 at 1:10 PM, Clint Byrum <clint at fewbar.com> 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?
> >
> The documentation currently points to the latest copy of the generated
> files when they're available. I'd like to continue having those generated
> and looked at by humans in reviews.
> I think if you asked non-devs, such as deployers, you'd find wider uses.
> Can you poll another group in addition to this mailing list?

The way I see it, the generated sample config file is itself
documentation. Perhaps that file should actually go where the docs go,
rather than sitting in the git tree.

With other libraries causing changes anyway, we're not really reviewing
every change anyway, otherwise I wouldn't have sent this message. We
weren't able to review what keystoneclient did before it broke our
gate. Keystoneclient isn't going to review the matrix of dependent repos
for breakage there either.

We do review the code changes that lead to the relevant changes in our
samples, and that _should_ be enough. It works the same with all of
our other code-born documentation (such as the Heat template guide). So
I'm comfortable saying that reviewers should be able to catch obvious
things that would break the sample configs from the code alone, in the
same way that reviewers would find such an error in other such generated

More information about the OpenStack-dev mailing list