[openstack-dev] [openstack][nova] Streamlining of config options in nova
Michael Still
mikal at stillhq.com
Wed Aug 12 20:08:26 UTC 2015
On Thu, Aug 13, 2015 at 4:29 AM, Sean Dague <sean at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150813/881c72f7/attachment.html>
More information about the OpenStack-dev
mailing list