[openstack-dev] Considerations when adding Nova config options

Jay Pipes jaypipes at gmail.com
Mon Aug 13 20:49:21 UTC 2012


+10

On 08/13/2012 07:44 AM, Mark McLoughlin wrote:
> Hi,
> 
> I just noticed we've added a new 'defer_iptables_apply' configuration
> option to Nova:
> 
>   https://bugs.launchpad.net/nova/+bug/1034401
> 
> The default value is False but AFAICT there is no reason why users would
> *not* want to change this to True.
> 
> Also, the docs for the option does nothing to help users decide whether
> they should change the option:
> 
>  +    cfg.BoolOpt('defer_iptables_apply',
>  +                default=False,
>  +                help='Whether to batch up the application of IPTables rules'
>  +                     ' during a host restart and apply all at the end of the'
>  +                     ' init phase'),
> 
> I can only see one justification for this being an option - perhaps
> we're unsure about the reliability of this "defer" mode and plan to
> switch to defer mode by default in future and remove the option. If so,
> it would be nice if the docs said something like:
> 
>   Set to True to evaluate this new experimental behaviour which is 
>   likely to become the default behaviour in a future version.
> 
> 
> Another similarish example is where we're considering adding an
> 'ignore_attach_device' option:
> 
>   https://bugs.launchpad.net/nova/+bug/1004328
> 
> Again, the default is False but AFAICT there's no reason users of the
> libvirt driver would *not* want to change this to True.
> 
> And again, the docs give no guidance to users about when they might want
> to change it to True.
> 
> 
> We now have roughly 500 configuration options in Nova. That's absolutely
> insane. Especially if some of them are set by default to some known
> broken value and we don't have docs to tell users to change them.
> 
> I'd like us to start rationalizing configuration options - removing
> some, marking others as "experimental", adding more helpful guidance to
> the docs, etc. - but I'd really like if we could make a better effort to
> not make the problem worse in the meantime :-)
> 
> Cheers,
> Mark.
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 



More information about the OpenStack-dev mailing list