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,
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
