<div dir="ltr"><br><div class="gmail_extra">On Wed, Nov 13, 2013 at 3:38 PM, Doug Hellmann <span dir="ltr"><<a href="mailto:doug.hellmann@dreamhost.com" target="_blank">doug.hellmann@dreamhost.com</a>></span> wrote:<br>
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">
On Wed, Nov 13, 2013 at 2:19 PM, Oleg Gelbukh <span dir="ltr"><<a href="mailto:ogelbukh@mirantis.com" target="_blank">ogelbukh@mirantis.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Doug,<br><div class="gmail_extra"><br><br><div class="gmail_quote">
<div>On Wed, Nov 13, 2013 at 9:49 PM, Doug Hellmann <span dir="ltr"><<a href="mailto:doug.hellmann@dreamhost.com" target="_blank">doug.hellmann@dreamhost.com</a>></span> wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><br>
<div class="gmail_quote">
<div><div><div>On Mon, Nov 11, 2013 at 6:08 PM, Mark McLoughlin <span dir="ltr"><<a href="mailto:markmc@redhat.com" target="_blank">markmc@redhat.com</a>></span> wrote:<br>
</div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><br>
</div>One thing worth trying would be to encode the validation rules in the<br>
config option declaration.<br>
<br>
Some rules could be straightforward, like:<br>
<br>
opts = [<br>
StrOpt('foo_url',<br>
validate_rule=cfg.MatchesRegexp('(git|http)://')),<br>
]<br>
<br>
but the rule you describe is more complex e.g.<br>
<br>
def validate_proxy_url(conf, group, key, value):<br>
if not conf.vnc_enabled:<br>
return<br>
if conf.ssl_only and value.startswith("http://"):<br>
raise ValueError('ssl_only option detected, but ...')<br>
<br>
opts = [<br>
StrOpt('novncproxy_base_url',<br>
validate_rule=validate_proxy_url),<br>
...<br>
]<br>
<br>
I'm not sure I love this yet, but it's worth experimenting with.<br></blockquote><div><br></div></div></div></div><div><div>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.</div>
<div><br></div><div>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. </div></div>
</div>
</div></div></blockquote><div><br></div><div>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:</div>
<div><br></div><div>[1] <a href="https://github.com/MirantisLabs/rubick/tree/master/rubick/schemas" target="_blank">https://github.com/MirantisLabs/rubick/tree/master/rubick/schemas</a></div><div>[2] <a href="https://github.com/MirantisLabs/rubick/blob/master/rubick/schemas/collector.py#L189" target="_blank">https://github.com/MirantisLabs/rubick/blob/master/rubick/schemas/collector.py#L189</a></div>
<div>[3] <a href="https://github.com/MirantisLabs/rubick/blob/master/rubick/schemas/generator.py" target="_blank">https://github.com/MirantisLabs/rubick/blob/master/rubick/schemas/generator.py</a></div><div><br></div><div>
I think it would be useful to discuss pros and cons of contributing parts of this code to oslo.config.</div></div></div></div></blockquote><div><br></div><div>There's definitely some overlap with the planned work from <a href="https://etherpad.openstack.org/p/icehouse-oslo-config-import-side-effects" target="_blank">https://etherpad.openstack.org/p/icehouse-oslo-config-import-side-effects</a> and the existing sample file generator, so it would be good to coordinate.</div>
<br></div></div></div></blockquote><div><br></div><div>Also worth keeping in mind that we now generate documentation from config files <<a href="http://docs.openstack.org/havana/config-reference/content/">http://docs.openstack.org/havana/config-reference/content/</a>>. 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.<br>
<br></div><div><br>Lorin<br></div></div><br>-- <br><div dir="ltr">Lorin Hochstein<br><div>Lead Architect - Cloud Services</div><div>Nimbis Services, Inc.</div><div><a href="http://www.nimbisservices.com" target="_blank">www.nimbisservices.com</a></div>
</div>
</div></div>