[openstack-dev] [oslo] config: deduce related options for config generator?

Markus Zoeller mzoeller at de.ibm.com
Wed May 4 14:47:04 UTC 2016


> From: Doug Hellmann <doug at doughellmann.com>
> To: openstack-dev <openstack-dev at lists.openstack.org>
> Date: 05/03/2016 07:04 PM
> Subject: Re: [openstack-dev] [oslo] config: deduce related options for
> config generator?
> 
> Excerpts from Markus Zoeller's message of 2016-05-03 18:26:50 +0200:
> > While working on [1] I came across a config option ("pybasedir")
> > which gets used as a base for many other options, for example
> > "state_path". The option "state_path" shows then a default value
> > "state_path = $pybasedir".
> > My question here is, is it possible/reasonable to enhance oslo.config
> > to add an information to "pybasedir" that is used as a base for other
> > config options?
> > My concern is, that one could change "pybasedir" and expect that only
> > this one single value changes, but actually one changes multiple other
> > config options as well. Making it explicit that "pybasedir" gets used
> > multiple times as a base could prevent confusion.
> > 
> > References:
> > [1] https://review.openstack.org/#/c/299236/7/nova/conf/paths.py
> > 
> > Regards, Markus Zoeller (markus_z)
> > 
> 
> (Sorry if this is a dupe, I'm having mail client issues.)
> 
> We can detect interpolated values in defaults, but those can also appear
> in user-provided values. There are also plenty of options that are
> related to each other without using interpolation.
> 
> Given that we have to handle the explicit cases anyway, and that
> interpolation isn't used all that often, I think it likely makes more
> sense to start with the explicit implementation and see how far that
> takes us before adding any automation.
> 
> Doug
> 

Yeah, interpolation is rarely used (at least in Nova). I only had the 
usage of interpolation in default values in mind. If the effort in 
oslo.config would be too big, it probably isn't reasonable to push
this. Thank you Doug, for checking the possibilities.

Regards, Markus Zoeller (markus_z)




More information about the OpenStack-dev mailing list