[all] Service-specific configuration options
I proposed a WIP change for oslo.config [1] last week that would allow us to specify what services (e.g. nova-compute, nova-scheduler, nova- api, etc.) an option applies to. This came about because of comments on another issue where we found no one could say with surety what services needed an option in their configuration option (which in turn brought up questions about why those services needed the option). It was suggested I bring the idea up on the mailing list before we proceeded any further with it so here I am. I'm interested in two things. Firstly, I'd like to know whether generation of per-service configuration files is actually something others find problematic? I'm imagining this is annoying for operators and those working on deployment tooling but I've never got any hard data to back up that assumption. Secondly, I didn't see anything in the likes of cinder, nova or neutron but has anyone else already worked on something like this? For what it's worth, I did explain why I've gone with the approach I have in the commit message, but that doesn't mean there aren't other options I could be missing. Stephen [1] https://review.openstack.org/#/c/625011/ PS: I've tagged this [all] as enumerating the projects this actually affected left me with at least a dozen tags before I was even done. Sorry for any possible noise.
Stephen Finucane <sfinucan@redhat.com> writes:
I proposed a WIP change for oslo.config [1] last week that would allow us to specify what services (e.g. nova-compute, nova-scheduler, nova- api, etc.) an option applies to. This came about because of comments on another issue where we found no one could say with surety what services needed an option in their configuration option (which in turn brought up questions about why those services needed the option). It was suggested I bring the idea up on the mailing list before we proceeded any further with it so here I am.
I'm interested in two things. Firstly, I'd like to know whether generation of per-service configuration files is actually something others find problematic? I'm imagining this is annoying for operators and those working on deployment tooling but I've never got any hard data to back up that assumption. Secondly, I didn't see anything in the likes of cinder, nova or neutron but has anyone else already worked on something like this? For what it's worth, I did explain why I've gone with the approach I have in the commit message, but that doesn't mean there aren't other options I could be missing.
Stephen
[1] https://review.openstack.org/#/c/625011/
PS: I've tagged this [all] as enumerating the projects this actually affected left me with at least a dozen tags before I was even done. Sorry for any possible noise.
Glance uses different entry points to produce service-specific configuration option sample files and documentation. See https://docs.openstack.org/glance/latest/configuration/index.html for example. -- Doug
On 12/17/2018 10:46 AM, Stephen Finucane wrote:
Secondly, I didn't see anything in the likes of cinder, nova or neutron but has anyone else already worked on something like this? For what it's worth, I did explain why I've gone with the approach I have in the commit message, but that doesn't mean there aren't other options I could be missing.
When Markus Zoeller was originally doing the nova config option cleanup [1] which included centralizing everything under nova/conf/ and also updating the documentation on all options to have a standard format, he also included a list of which services used each option. Over time that was dropped, presumably because (1) it's hard as hell to maintain with as many options as nova has and as much code motion that nova has and (2) it's hard to know if it is useful at all given I expect most people are pushing config option changes to a single nova.conf that gets pushed to all of their services (there are especially some options which simply don't work if they aren't in nova-api and nova-compute for example [reclaim_instance_interval]). John Garbutt and/or Michael Still might remember more, but that's my recollection. So I'd rather not re-open this can of worms. If a particular option or set of options are hairy with service configuration, then call those out specifically in the help for those options. Having said that, I recently helped someone in IRC who couldn't figure out how to get vendor data from the metadata API into the config drive and it was because they weren't setting some metadata API config options in nova-compute where the config drive is built. That was likely due to confusion because the "vendordata_jsonfile_path" option in nova is in the [api] group which would naturally make one think that's only needed in nova-api, but it's also used in nova-compute when building a config drive. As a result, I opted to cleanup the help and our docs [2]. Anyway, I think we've got wayyyyy bigger problems to solve than dig back into a multi-release effort to document where all of our config options are used. [1] https://specs.openstack.org/openstack/nova-specs/specs/mitaka/implemented/ce... [2] https://review.openstack.org/#/c/624518/ -- Thanks, Matt
participants (3)
-
Doug Hellmann
-
Matt Riedemann
-
Stephen Finucane