Open Stack

On Mon, Nov 11, 2013 at 6:08 PM, Mark McLoughlin <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.

Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131113/e89dc936/attachment.html>