Removing import-time side-effects from oslo.config consumers
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
- Status:
- Complete
- Approver:
- None
- Priority:
- Undefined
- Drafter:
- Doug Hellmann
- Direction:
- Needs approval
- Assignee:
- Doug Hellmann
- Definition:
- Obsolete
- Series goal:
- None
- Implementation:
-
Unknown
- Milestone target:
- None
- Started by
- Completed by
- Doug Hellmann
Related branches
Related bugs
Sprints
Whiteboard
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 https:/
How does a cinder deployer know which group names to use for their configuration? -- dhellmann
It is defined in the cinder.conf file
https:/
Work Items
Dependency tree
* Blueprints in grey have been implemented.
