Comment 4 for bug 1151665

Ok, thanks for the test case

Here's a scarey traceback:

  File "a.py", line 21, in <module>
    print dict(a)
  File "/home/markmc/git/openstack/oslo-config/oslo/config/cfg.py", line 1676, in __getitem__
    return self.__getattr__(key)
  File "/home/markmc/git/openstack/oslo-config/oslo/config/cfg.py", line 1672, in __getattr__
    return self._conf._get(name, self._group)
  File "/home/markmc/git/openstack/oslo-config/oslo/config/cfg.py", line 1477, in _get
    value = self._substitute(self._do_get(name, group))
  File "/home/markmc/git/openstack/oslo-config/oslo/config/cfg.py", line 1506, in _do_get
    value = opt._get_from_config_parser(self._cparser, section)
  File "/home/markmc/git/openstack/python-keystoneclient/keystoneclient/openstack/common/cfg.py", line 669, in _get_from_config_parser
    self._cparser_get_with_deprecated(cparser, section)]
  File "/home/markmc/git/openstack/python-keystoneclient/keystoneclient/openstack/common/cfg.py", line 552, in _cparser_get_with_deprecated
    return cparser.get(section, [self.dest])
  File "/home/markmc/git/openstack/oslo-config/oslo/config/cfg.py", line 1006, in get
    traceback.print_stack()

The issue is that there is an internal contract in cfg between the Opt class and the MultiConfigParser class

With keystoneclient 0.2.2 it's an oslo.config.cfg.ConfigOpts object calling a keystoneclient.openstack.common.cfg.Opt objects which, in turn, calls back to an oslo.config.cfg.MultiConfigParser object

In 2013.1b4 the oslo.config.cfg.MultiConfigParser interface matches the keystone.openstack.common.MultiConfigParser interface but in 2013.1b4, oslo.config.cfg.MultiConfigParser has changed but keystoneclient.openstack.common.cfg.Opt is obviously still expecting the old interface

The conclusion remains the same, I think - we need a new release of keystoneclient which will use oslo.config