[openstack-dev] Considerations when adding Nova config options

Pádraig Brady P at draigBrady.com
Tue Aug 21 10:36:10 UTC 2012


On 08/14/2012 10:08 AM, Mark McLoughlin wrote:
> On Tue, 2012-08-14 at 09:59 +0200, Thierry Carrez wrote:
>> Maybe we could add some category/priority/experimentalness declaration
>> where the option is defined, so that tools could pick it up and use it
>> to generate prettier documentation ?

category is somewhat represented in the generated nova.conf.sample.
Perhaps we could improve this representation based
on an implicit structure of the modules,
which may need to be augmented with category tagging.
Something I've been meaning to look at...

> One idea I've been toying with is allowing options to be marked as
> "experimental" and adding a "--disable-experimental" command line
> option. Then we could run with --disable-experimental by default (from
> e.g. init scripts, devstack etc.) so that users have to explicitly
> re-enable the experimental options in nova.conf if they want to use
> them.

We've so many config options now that more tags are appropriate.
Ones that come to mind now are:

experimental, deprecated, mandatory

Now 'experimental' strays into the redundant category IMHO,
but if really needed, then it's better to have such options
explicitly tagged, and they can move to 'deprecated' (the
option, not the feature), as the feature matures.

I've written some general notes before on why
one should try to avoid config options at all costs:
http://www.pixelbeat.org/docs/power_of_the_default.html

cheers,
Pádraig.



More information about the OpenStack-dev mailing list