Make cfg group names case insensitive

Registered by Mark McLoughlin on 2013-03-05

Nova uses lowercase group names e.g.

 [baremetal]
 [cells]
 [conductor]
 ..

whereas Quantum uses lots of uppercase group names:

 [AGENT]
 [DATABASE]
 [DRIVER]
 ...

*sigh*

This thread brought the issue up: http://lists.openstack.org/pipermail/openstack-dev/2013-March/thread.html#6309

One option is to make group names case insensitive but, even then, we probably also want the sample configuration files for all projects to consistently use lower or upper case. IOW, we should move Quantum to use lowercase group names :)

Here's a proposal:

  - log a deprecation warning if a project registers a group name that is not all lowercase before normalizing it to lowercase

  - in ConfigOpts getattr/getitem, just normalize the group name to lowercase and log a deprecation warning if it's a valid group

  - change Quantum's code to register and reference the groups in lower case

  - change Quantum's sample config files to use lowercase section names

That way, Havana will be using all-lowercase but Grizzly config files will still work without any warnings being printed

Other compat issues to think about:

 - if you're using Grizzly and you update to a newer version of oslo.config, you'll get a bunch of new warnings

 - if you're using CLI options with a group, it'll break - e.g. if you registered a 'FOO' group and a 'bar' CLI option, then the CLI argument would have been --FOO-bar. I don't know of anyone doing that and I think it's highly unlikely anyone would have done it.

I think we should continue using [DEFAULT] as the default section since that's what ConfigParser does

---

In the end, the plan became ...

The basic goal here is that we want to support the legacy use of group names like DATABASE in config files

That means:

1) if the API user registers a group called 'database', then we want to support reading values for the group from both database or DATABASE

This is purely about support for legacy group names in config files.

2) when the API user registers a group called 'database', then CONF.database should be how to reference it. When they register a group called 'DATABASE', then CONF.DATABASE should be how the reference it.

This ensures we're not making an incompatible API change - i.e. quantum's code will continue working and they only need to do s/CONF.DATABASE/CONF.database/ when they switch to oslo's DB code

3) the behaviour of [DEFAULT] should be unchanged so that users don't start switching to [default] and breaking existing tools

4) a deprecation warning to users/admins (i.e. a "you should fix your config file" warning) could *perhaps* be useful ... but it would need to be a one-time warning at startup per-file, not a warning every time a config value is accessed

We can live without this, though - we're not going to ever remove this case normalization semantics, so we don't need to be too active about getting users to switch to lowercase groups

Blueprint information

Status:
Complete
Approver:
Mark McLoughlin
Priority:
Medium
Drafter:
Mark McLoughlin
Direction:
Approved
Assignee:
Zhongyue Luo
Definition:
Approved
Series goal:
Accepted for havana
Implementation:
Implemented
Milestone target:
milestone icon 2013.2
Started by
Zhongyue Luo on 2013-05-01
Completed by
Zhongyue Luo on 2013-05-10

Related branches

Sprints

Whiteboard

I think the steps should be
1. Change _get/register_group of ConfigOpts and __init__ of OptGroup to normalize the group name to lowercase and log a deprecation warning if it's a valid group
* __getitem__ calls __getattr__ which eventually calls _get
2. Change Quantum's code to register and reference the groups in lower case
3. Change Quantum's sample config files to use lowercase section names

Am I missing anything?
-zyluo

How can we avoid circular import issues when logging the deprecation message?
oslo.log is importing oslo.config.cfg when oslo.config.cfg needs to import oslo.log to log a message.
Don't use oslo.log?
-zyluo

https://review.openstack.org/#/c/27887/
-zyluo

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.