Removing import-time side-effects from oslo.config consumers

Registered by Doug Hellmann

Most apps use oslo.config by relying on options to be registered as code is loaded. Many modules throughout the OpenStack code base have blocks that import the global config object from oslo.config and then register options on the object. This means importing a module changes global state shared by the application, in a way that cannot be undone or reproduced by unit tests. This proposal describes a way to avoid having import-time side-effects while maintaining or improving our current level of discoverability.

Blueprint information

Doug Hellmann
Needs approval
Doug Hellmann
Series goal:
Milestone target:
Completed by
Doug Hellmann

Related branches



Nice work Doug. I commented inline in the etherpad.

Summary - you're tackling two things: how options are registered and how they are discovered. I think oslo.messaging shows the way forward for the former, but I really like your idea for the latter. -- @markmc

Thanks, Mark, I'll take a closer look at how messaging handles the registration side of things so we can do it consistently. I replied to some of your other comments inline. -- dhellmann

For some reason I thought re-registering an option always caused an exception. I see that's only the case when the option configuration differs. Given that, I like the way oslo.messaging works. If you think using entry points to discover the options is still useful for generating example files and documentation, I can rework the blueprint with that as the focus. Otherwise it seems like we can drop the whole thing. -- dhellmann

We do need a good way for libraries to advertise their options for the config file generation and documentation. The entry points idea does sound like a nice, standardized way of doing it. -- markmc

OK. I'm tempted to keep this blueprint, but have it be about helping consumers of oslo.config change their practices. The discovery stuff could then go into another blueprint. It would still be nice if the discovery function returned a value that could be passed directly to register_opts(), so the functions could be used for registering the options at runtime. Maybe a helper method? I'll give that more thought. - @dhellmann

I also agree with the entry point solution for this issue. However entry points are static and there is need for dynamic registeration in Cinder. Cinder has a unique way of registering options. If you look at the volume manager in, here the manager takes a group name passed from the caller and registers multiple configurations for a given set of options. See the docstring in Any thoughts on how to handle this case? -- zyluo

How does a cinder deployer know which group names to use for their configuration? -- dhellmann

It is defined in the cinder.conf file --zyluo


Work Items

Dependency tree

* Blueprints in grey have been implemented.

This blueprint contains Public information 
Everyone can see this information.