Open Stack

Excerpts from Ben Nemec's message of 2016-07-08 13:27:04 -0500:
> On 07/08/2016 10:58 AM, Doug Hellmann wrote:
> > Excerpts from Ben Nemec's message of 2016-07-08 10:24:54 -0500:
> >> On 07/08/2016 09:14 AM, ChangBo Guo wrote:
> >>> Hi ALL,
> >>>
> >>> I have been working a bug [1] about option value interpolation in
> >>> oslo.config[2], in short, option value interpolation can't handle
> >>> password containing special characters from environment variable and I 
> >>> proposed a fix of provide way to forbid option value interpolation
> >>> explicitly[3]. 
> >>>
> >>> copy of Doug Hellmann's coments:
> >>>
> >>> "The problem is that the end user who is setting the value of the option
> >>> cannot control whether the option will do interpolation or not. So the
> >>> programmer who defines the option has to make that choice, and then we
> >>> can't change it because that would break existing deployments. The
> >>> result is that end users won't know for any given option whether
> >>> interpolation works or not, and if not why (did they do something wrong,
> >>> or is it not supported).
> >>>
> >>> I've set -2 on this patch because I think it's a bad approach. I see 2
> >>> other ways we could solve the problem you describe (and I agree that
> >>> it's an issue we should help with).
> >>>
> >>> 1. We could have an option that turns off interpolation globally, and
> >>> let the user control that by setting the flag in their configuration
> >>> file. I'm not sure I like this, but it does give you what you're looking
> >>> for at the risk of breaking applications that are relying on
> >>> interpolation, like the nova example.
> >>
> >> This feels like a big hammer for a relatively small edge case, and as
> >> you note it doesn't handle the case where you want to use interpolation,
> >> but have an environment variable default that breaks when interpolated.
> >>
> >>>
> >>> 2. We could disable interpolation when we get values from environment
> >>> variables. That would be a big behavioral change, so we would need to
> >>> think about how to roll it out carefully. For example, do we provide a
> >>> helper function to give to application developers who are setting
> >>> default values to environment variables so the variable value can be
> >>> escaped to avoid interpolation? Or do we build it into the Opt class
> >>> somehow? I think I like the helper function approach but we should give
> >>> it more thought."
> >>
> >> One possibility would be an "env_default" (or something) parameter to
> >> Opt that would read the env var, escape it as necessary, and set the opt
> >> default to the escaped value.  Then we could recommend that people stop
> >> using os.environ for setting defaults this way.  Using default and
> >> env_default at the same time would raise an exception.
> > 
> > That sounds a lot like my helper function example, but builds the
> > concept of taking a default from an environment variable into Opt.
> 
> Yeah, I was mostly +1'ing that suggestion and then brainstorming how to
> integrate it into the opt definition.  This seemed like the simplest way
> to do it, but the benefit of a separate helper function would be if
> there are other places we might want to do the same thing besides just
> the Opt constructor.  I could see someone wanting to set a None default
> and then conditionally set the default to an environment variable in
> their code, so maybe standalone would be better.

On the other hand, if we build "get a default from an environment
variable" into Opt, we can include that information in the help and
sample config output.

If we make the escaping function public, and then also use it to
implement the "environment_variable" behavior in Opt, that would give us
the best of both solutions.

Doug