Open Stack

All,

Let me start with the TLDR;

Cinder, Nova and Neutron have lots of configuration options that need to 
be processed by oslo-config-generator to create the 
<project>.conf.sample file.  There are a couple of different ways this 
could be done.  I have one proposal out, which has raised concerns, 
there is a second approach that could be taken which I am proposing 
below.  Please read on if you have a strong opinion on the precedent we 
will try to set in Cinder.  :-)

We discussed in the oslo meeting a couple of weeks ago a plan for how 
Cinder was going to blaze a trail to the new oslo-config-generator.  The 
result of that discussion and work is here:  [1]  It needs some more 
work but has the bare bones pieces there to move to using 
oslo-config-generator.

With the change I have written extensive hacking checks that ensure that 
any lists that are registered with register_opts() are included in the 
base cinder/opts.py file that is then a single entry point that pulls 
all of the options together to generate the cinder.conf.sample file.  
This has raised concern, however, that whenever a developer adds a new 
list of configuration options, they are going to have to know to go back 
to cinder/opts.py and add their module and option list there.  The 
hacking check should catch this before code is submitted, but we are 
possibly setting ourselves up for cases where the patch will fail in the 
gate because updates are not made in all the correct places and because 
pep8 isn't run before the patch is pushed.

It is important to note, that this will not happen every time a 
configuration option is changed or added, as was the case with the old 
check-uptodate.sh script.  Only when a new list of configuration options 
is added which is a much less likely occurrence.  To avoid this 
happening at all it was proposed by the Cinder team that we use the code 
I wrote for the hacking checks to dynamically go through the files and 
create cinder/opts.py whenever 'tox -egenconfig' is run.  Doing this 
makes me uncomfortable as it is not consistent with anything else I am 
familiar with in OpenStack and is not consistent with what other 
projects are doing to handle this problem.  In discussion with Doug 
Hellman, the approach also seemed to cause him concern.  So, I don't 
believe that is the right solution.

An alternative that may be a better solution was proposed by Doug:

We could even further reduce the occurrence of such issues by moving the 
list_opts() function down into each driver and have an entry point for 
oslo.config.opts in setup.cfg for each of the drivers.  As with the 
currently proposed solution, the developer doesn't have to edit a top 
level file for a new configuration option.  This solution adds that the 
developer doesn't have to edit a top level file to add a new 
configuration item list to their driver.  With this approach the change 
would happen in the driver's list_opts() function, rather than in 
cinder/opts.py .  The only time that setup.cfg would needed to edited is 
when a new package is added or when a new driver is added.  This would 
reduce some of the already minimal burden on the developer.  We, 
however, would need to agree upon some method for aggregating together 
the options lists on a per package (i.e. cinder.scheduler, cinder.api) 
level.  This approach, however, also has the advantage of providing a 
better indication in the sample config file of where the options are 
coming from.  That is an improvement over what I have currently proposed.

Does Doug's proposal sound more agreeable to everyone?  It is important 
to note that the fact that some manual intervention is required to 
'plumb' in the new configuration options was done by design.  There is a 
little more work required to make options available to 
oslo-config-generator but the ability to use different namespaces, 
different sample configs, etc were added with the new generator.  These 
additional capabilities were requested by other projects.  So, moving to 
this design does have the potential for more long-term gain.

Thanks for taking the time to consider this!

Jay

[1] https://review.openstack.org/#/c/165431/