Open Stack

On Wed, Nov 13, 2013 at 3:38 PM, Doug Hellmann
<doug.hellmann at dreamhost.com>wrote:

>
>
>
> On Wed, Nov 13, 2013 at 2:19 PM, Oleg Gelbukh <ogelbukh at mirantis.com>wrote:
>
>> Doug,
>>
>>
>> On Wed, Nov 13, 2013 at 9:49 PM, Doug Hellmann <
>> doug.hellmann at dreamhost.com> wrote:
>>
>>>
>>>
>>>
>>>  On Mon, Nov 11, 2013 at 6:08 PM, Mark McLoughlin <markmc at redhat.com>wrote:
>>>
>>>>
>>>> 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.
>>>
>>
>> We implement similar approach in Rubick [1]. Collector script generates
>> configuration schema from code [2], while generator script [3] allows to
>> have different versions of configuration schema:
>>
>> [1] https://github.com/MirantisLabs/rubick/tree/master/rubick/schemas
>> [2]
>> https://github.com/MirantisLabs/rubick/blob/master/rubick/schemas/collector.py#L189
>> [3]
>> https://github.com/MirantisLabs/rubick/blob/master/rubick/schemas/generator.py
>>
>> I think it would be useful to discuss pros and cons of contributing parts
>> of this code to oslo.config.
>>
>
> There's definitely some overlap with the planned work from
> https://etherpad.openstack.org/p/icehouse-oslo-config-import-side-effectsand the existing sample file generator, so it would be good to coordinate.
>
>
Also worth keeping in mind that we now generate documentation from config
files <http://docs.openstack.org/havana/config-reference/content/>. If
we're going to embed typechecking-like constraints into the options, I'd
like to have a way to transform these constraints into
(non-Python-programmer) human-readable text when generating the config
guide. Since that's tricky to do for arbitrary Python code, we may want to
come up with a scheme that can be used both for validation and that can be
easily transformed into a natural-language description.


Lorin

-- 
Lorin Hochstein
Lead Architect - Cloud Services
Nimbis Services, Inc.
www.nimbisservices.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131113/8a9351c5/attachment.html>