On Wed, Nov 13, 2013 at 3:38 PM, Doug Hellmann <doug.hellm...@dreamhost.com>wrote:
> > > > On Wed, Nov 13, 2013 at 2:19 PM, Oleg Gelbukh <ogelb...@mirantis.com>wrote: > >> Doug, >> >> >> On Wed, Nov 13, 2013 at 9:49 PM, Doug Hellmann < >> doug.hellm...@dreamhost.com> wrote: >> >>> >>> >>> >>> On Mon, Nov 11, 2013 at 6:08 PM, Mark McLoughlin <mar...@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
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev