Open Stack

> -----Original Message-----
> From: Mark McLoughlin [mailto:markmc at redhat.com]
> Sent: 18 June 2014 06:58
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [glance] Unifying configuration file
> 
> 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.

Yes and the users who relied on those config files in the github were really upset about that.
> 
> 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.

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

We can learn from others, can't we? 
I think the key point here is part of the comment in the Cinder discussion to remove the sample config 	https://review.openstack.org/#/c/96581/ (Mathieu Jun 6 7:53 PM):
"""
Note that it's not just about Cinder, its about all the other projects. They [ops; Erno add] don't track changes in Gerrit, its not something they do in their day-to-day job. It just happened that we heard about this change on the openstack-operators mailinglist.
"""

We are again having this discussion on the dev list without involving the most important group, our ops. 
> 
> 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.


+100
I'd add to that: until olso.config can provide us more than one config file generated automatically. Now lets remember that if you run glance with the registry on somewhere else than devstack you are most probably running registry and API on different servers. Making them relying on single config is about as smart idea as saying that we should not provide project independent configs, but combine all the configs to a single OpenStack config file with nice note "good luck trying to figure out what bits you need from this". That would probably make sense if you never run these out of devstack having all the services on same machine anyways.
> 
> Mark.
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

- Erno (jokke) Kuvaja