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. > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
