[openstack-dev] [oslo][cinder][nova][neutron] going forward to oslo-config-generator ...

Walter A. Boring IV walter.boring at hp.com
Mon Mar 23 20:49:48 UTC 2015

Maybe we can leverage Cinder's use of the abc in the drivers.py now.   
We could create an OptionsVD that drivers would add and implement.  The 
config generator could inspect objects looking for OptionsVD and then 
call list_opts() on it.   That way, driver maintainers don't also have 
to patch the setup.cfg.   Just require new drivers to add OptionsVD and 
implement list_opts().   We could put a hacking check in for that as well.

My $0.02,
> 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.

More information about the OpenStack-dev mailing list