Open Stack

Hey

On Tue, 2014-06-17 at 17:43 +0200, Julien Danjou wrote:
> On Tue, Jun 17 2014, Arnaud Legendre wrote:
> 
> > @ZhiYan: I don't like the idea of removing the sample configuration file(s)
> > from the git repository. Many people do not want to have to checkout the
> > entire codebase and tox every time they have to verify a variable name in a
> > configuration file. I know many people who were really frustrated where they
> > realized that the sample config file was gone from the Nova repo.
> > However, I agree with the fact that it would be better if the sample was
> > 100% accurate: so the way I would love to see this working is to generate
> > the sample file every time there is a config change (this being totally
> > automated (maybe at the gate level...)).
> 
> You're a bit late on this. :)
> So what I did these last months (year?) in several project, is to check
> at gate time the configuration file that is automatically generated
> against what's in the patches.
> That turned out to be a real problem because sometimes some options
> changes from the eternal module we rely on (e.g. keystone authtoken or
> oslo.messaging). In the end many projects (like Nova) disabled this
> check altogether, and therefore removed the generated configuration file
> From the git repository.

For those that casually want to refer to the sample config, what would
help if there was Jenkins jobs to publish the generated sample config
file somewhere.

For people installing the software, it would probably be nice if pbr
added 'python setup.py sample_config' or something.

> > @Julien: I would be interested to understand the value that you see of
> > having only one config file? At this point, I don't see why managing one
> > file is more complicated than managing several files especially when they
> > are organized by categories. Also, scrolling through the registry settings
> > every time I want to modify an api setting seem to add some overhead.
> 
> Because there's no way to automatically generate several configuration
> files with each its own set of options using oslo.config.

I think that's a failing of oslo.config, though. Glance's layout of
config files is useful and intuitive.

> Glance is (one of?) the last project in OpenStack to manually write its
> sample configuration file, which are not up to date obviously.

Neutron too, but not split out per-service. I don't find Neutron's
config file layout as intuitive.

> So really this is mainly about following what every other projects did
> the last year(s).

There's a balance here between what makes technical sense and what helps
users. If Glance has support for generating a unified config file while
also manually maintaining the split configs, I think that's a fine
compromise.

Mark.