Open Stack

On Fri, 2013-05-03 at 10:25 -0400, Monty Taylor wrote:
> 
> On 05/03/2013 10:16 AM, Flavio Percoco wrote:
> > Hi,
> > 
> > NOTE: Recently, something similar to $topic was discussed[0] in this list.
> > 
> > I was looking into a glance-manage "bug"[1] and found out that oslo.config
> > gives priority to parameters configured in config files over the ones
> > passed in the CLI (I missed the part that says: "Option values in
> > config files override those on the command line"). Although I understand
> > it was designed like that, I think this
> > behaviour is wrong.
> > 
> > Besides the fact that this is causing some confusion to CLI tools
> > users (see glance-manage bug), it makes it impossible to define
> > configuration parameters that are meant to be overridden by CLI
> > arguments.
> > 
> > That being said, I would like to propose to invert that behaviour and
> > let CLI arguments override configuration parameters. Reasoning behind
> > this is that it is already possible to define config parameters that
> > are hidden from the CLI, which means that parameters that shouldn't be
> > overridden by the CLI should not be exposed there.
> 
> I agree. I believe the natural order of things is:
> 
> - Default value in source code
> - Overridden by value in config file
> - Overridden by value in environment variable
> - Overridden by value given as command line option
> 
> Basically due to the relative permanence of each.

I think you hit the nail on the head with "the relative permanence of
each".

With a service started by the likes of systemd, the command line
arguments are the most permanent - you're much more likely to change the
config file than the command line arguments used by the service.

For example, Fedora's systemd config for nova-api is:

  /usr/bin/nova-api --config-file /etc/nova/nova.conf --logfile /var/log/nova/api.log

and you'd expect setting logfile in the config file to change the
location of the log file.

The behaviour of gflags in this case was determined by where on the
command line the config file was specified - we don't have a way to do
that in cfg, but maybe we could figure it out.

The "permanence order" seems reversed in the case  of tools like
nova-manage. So, maybe the solution is to have a flag which specifies
the order and CLIs like nova-manage would set that flag, but the
behaviour of services would stay the same.

Cheers,
Mark.