neutron returns objects other than oslo_config.cfg.Opt instances from list_opts
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Compute (nova) |
Fix Released
|
High
|
Pavlo Shchelokovskyy | ||
keystoneauth |
Invalid
|
Undecided
|
Unassigned | ||
neutron |
Fix Released
|
High
|
Jamie Lennox |
Bug Description
The neutron function for listing options for use with the configuration generator returns things that are not compliant with the oslo_config.cfg.Opt class API. At the very least this includes the options from keystoneauth1, but I haven't looked to find if there are others.
We'll work around this for now in the configuration generator code, but in the future we will more strictly enforce the API compliance by refusing to generate a configuration file or by leaving options out of the output.
The change blocked by this issue is: https:/
One failure log showing the issue is: http://
The neutron code triggering the issue is in: http://
The best solution would be to fix keystoneauth to support option discovery natively using proper oslo.config Opts.
Changed in keystoneauth: | |
status: | New → Won't Fix |
status: | Won't Fix → Incomplete |
Changed in nova: | |
assignee: | nobody → Pavlo Shchelokovskyy (pshchelo) |
importance: | Undecided → High |
Changed in neutron: | |
importance: | Undecided → Low |
tags: | added: config mitaka-backport-potential |
tags: | added: neutron-proactive-backport-potential |
Changed in keystoneauth: | |
status: | Incomplete → Invalid |
tags: | removed: neutron-proactive-backport-potential |
tags: | removed: mitaka-backport-potential |
Keystoneauth will not natively depend on oslo_config for everything (unless there is a drastic change) due to the fact that it has made efforts to not be locked into depending on oslo.* libraries. This was a key factor in it's original design to ensure we didn't get into any weird dependency issues and allowing it to be part of swift/swiftclient code bases.
Keeping this design in mind, what would be the correct approach? I would prefer to see oslo_config understand a clear "template" that can be converted into a proper opt for the generator or similar.