On Thu, Aug 13, 2015 at 4:29 AM, Sean Dague <s...@dague.net> wrote: > On 08/12/2015 02:23 PM, Jay Pipes wrote: > > On 08/12/2015 01:20 PM, Markus Zoeller wrote: > > <snip> > >> The three questions I have with every config option: > >> 1) which service(s) access this option? > >> 2) what does it do? / what's the impact? > >> 3) which other options do I need to tweek to get the described impact? > > > > All excellent questions that really should be answered in both the help > > string for the option as well as the documentation here: > > > > > http://docs.openstack.org/havana/config-reference/content/list-of-compute-config-options.html > > > > > > Note that the above link is generated, IIRC, from the code, so > > increasing the details in option descriptions (help string) should show > > up there. Anne is that assumption correct? > > > >> Would it make sense to stage the changes? > >> M cycle: move the config options out of the modules to another place > >> (like the approach Sean proposed) and annotate them with > >> the services which uses them >
Do we see https://review.openstack.org/#/c/205154/ as a reasonable example of such centralization? If not, what needs to change there to make it an example of that centralization? I see value in having a worked example people can follow before we attempt a large number of these moves. > >> N cycle: inject the options into the drivers and eliminate the global > >> variables this way (like Daniel et al. proposed) > > > > +1. I think the above is an excellent plan. You have my support. > > I think this is a great plan. I agree with both steps, and the order in > tackling them. Thanks for taking this on. Michael -- Rackspace Australia
__________________________________________________________________________ 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
