Open Stack

Excerpts from Walter A. Boring IV's message of 2015-03-23 13:49:48 -0700:
> 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.

If I understand you correctly, you're proposing to add a list_opts()
function to cinder somewhere that uses a separate set of entry points to
find the drivers and then pulls all of their options from the driver
class using a method that has to exist based on the abstract base class
contract. If that's right, I like the idea.

Doug

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