[openstack-dev] [glance] Unifying configuration file
doug.hellmann at dreamhost.com
Wed Jun 18 13:29:34 UTC 2014
On Wed, Jun 18, 2014 at 1:58 AM, Mark McLoughlin <markmc at redhat.com> wrote:
> 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.
We talked at one point about having it added to one of the doc builds.
Since an accurate file requires having all of the dependencies for the
app installed, it might be easiest to do it in the developer doc build
where that will already be the case. Ultimately we would want it in
the config guide as well.
> 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.
The config generator lets you specify the modules, libraries, and
files to be used to generate a config file. It even has a way to
specify which files to ignore. So I think we have everything we need
in the config generator, but we need to run it more than once, with
different inputs, to generate multiple files.
>> 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
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
More information about the OpenStack-dev