Open Stack

On 13/11/13 18:49, Doug Hellmann wrote:
> 
> 
> 
> On Mon, Nov 11, 2013 at 6:08 PM, Mark McLoughlin <markmc at redhat.com
> <mailto:markmc at redhat.com>> wrote:
> 
>     Hi Nikola,
> 
>     On Mon, 2013-11-11 at 12:44 +0100, Nikola Đipanov wrote:
>     > Hey all,
>     >
>     > During the summit session on the the VMWare driver roadmap, a topic of
>     > validating the passed configuration prior to starting services came up
>     > (see [1] for more detail on how it's connected to that specific
>     topic).
>     >
>     > Several ideas were thrown around during the session mostly
>     documented in
>     > [1].
>     >
>     > There are a few more cases when something like this could be
>     useful (see
>     > bug [2] and related patch [3]), and I was wondering if a slightly
>     > different approach might be useful. For example use an already
>     existing
>     > validation hook in the service class [4] to call into a validation
>     > framework that will potentially stop the service with proper
>     > logging/notifications. The obvious benefit would be that there is no
>     > pre-run required from the user, and the danger of running a
>     > misconfigured stack is smaller.
> 
>     One thing worth trying would be to encode the validation rules in the
>     config option declaration.
> 
>     Some rules could be straightforward, like:
> 
>     opts = [
>       StrOpt('foo_url',
>              validate_rule=cfg.MatchesRegexp('(git|http)://')),
>     ]
> 
>     but the rule you describe is more complex e.g.
> 
>     def validate_proxy_url(conf, group, key, value):
>         if not conf.vnc_enabled:
>             return
>         if conf.ssl_only and value.startswith("http://"):
>             raise ValueError('ssl_only option detected, but ...')
> 
>     opts = [
>       StrOpt('novncproxy_base_url',
>              validate_rule=validate_proxy_url),
>       ...
>     ]
> 
>     I'm not sure I love this yet, but it's worth experimenting with.
> 
> 
> One thing to keep in mind with the move to calling register_opt() at
> runtime instead of import time is the service may run for a little while
> before it reaches the point in the code where the option validation code
> is triggered. So I like the idea, but we may want a shortcut for validation.
> 
> We could add a small app to oslo.config that will load the options in
> the same way the conf generator and doc tool will, but then also read
> the configuration file and perform the validation. Another benefit of a
> separate tool is it could produce a full list of warnings and errors,
> rather than having the service stop on each bad value.
> 

Another issue that we might want to try and solve with this (and imho
another reason to keep the framework for this in oslo) is that we might
want to make these update aware, and allow for some graceful degradation
or something similar when for example an updated service is stated with
an outdated config.

Maybe Dan could weigh in on this?

N.

> Doug
> 
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>