We have an issue in Heat where the sample config generator from Oslo is
currently broken (see bug #1288586). Unfortunately it turns out that
there is no fix to the generator script itself that can do the Right
Thing for both Heat and Nova.
A brief recap on how the sample config generator works: it goes through
all of the files specified and finds all the ConfigOpt objects at the
top level. It then searches for them in the registered options, and
returns the name of the group in which they are registered. Previously
it looked for the identical object being registered, but now it just
looks for any equivalent ones. When you register two or more equivalent
options, the second and subsequent ones are just ignored by oslo.config.
The situation in Heat is that we have a bunch of equivalent options
registered in multiple groups. This is because we have a set of options
for each client library (i.e. python-novaclient, python-cinderclient,
&c.), with each set containing equivalent options (e.g. every client has
an "endpoint_type" option for looking up the keystone catalog). This
used to work, but now that equivalent options (and not just identical
options) match when searching for them in a group, we just end up with
multiple copies of each option in the first group to be searched, and
none in any of the other groups, in the generated sample config.
Nova, on the other hand, has the opposite problem (see bug #1262148).
Nova adds the auth middleware from python-keystoneclient to its list of
files to search for options. That middleware imports a file from
oslo-incubator that registers the option in the default group - a
registration that is *not* wanted by the keystone middleware, because it
registers an equivalent option in a different group instead (or, as it
turns out, as well). Just to make it interesting, Nova uses the same
oslo-incubator module and relies on the option being registered in the
default group. Of course, oslo-incubator is not a real library, so it
gets registered a second time but ignored (since an equivalent one is
already present). Crucially, the oslo-incubator file from
python-keystoneclient is not on the list of extra modules to search in
Nova, so when the generator script was looking for options identical to
the ones it found in modules, it didn't see this option at all. Hence
the change to looking for equivalent options, which broke Heat.
Neither comparing for equivalence nor for identity in the generator
script can solve both use cases. It's hard to see what Heat could or
should be doing differently. I think it follows that the fix needs to be
in either Nova or python-keystoneclient in the first instance.
One option I suggested was for the auth middleware to immediately
deregister the extra option that had accidentally been registered upon
importing a module from oslo-incubator. I put up patches to do this, but
it seemed to be generally agreed by Oslo folks that this was a Bad Idea.
Another option would be to specifically include the relevant module from
keystoneclient.openstack.common when generating the sample config. This
seems quite brittle to me.
We could fix it by splitting the oslo-incubator module into one that
provides the code needed by the auth middleware and one that does the
registration of options, but this will likely result in cascading
changes to a whole bunch of projects.
Does anybody have any thoughts on what the right fix looks like here?
Currently, verification of the sample config is disabled in the Heat
gate because of this issue, so it would be good to get it resolved.
cheers,
Zane.
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
