Open Stack

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.

> 
> So the shaker example would look like:
> 
> cfg.StrOpt('os-password', metavar='<auth-password>',
>            env_default='OS_PASSWORD',
>            sample_default='',
>            help='Authentication password, defaults to env[OS_PASSWORD].')
> 
> It does require that developers DTRT when pulling defaults from the env,
> but IMHO that's better than a backwards incompatible change or requiring
> that users DTRT, which seem to be the alternatives here.
> 
> I suppose it would break anyone who happened to be using interpolation
> of a default from the env, but I feel like that's unlikely and a much
> less common case than "my password has a $ character in it".

That's also my assumption. I think this has come up before, especially
since a lot of the password generators out there like to use characters
the parser considers "special."

Doug

> 
> > 
> > I would like to collect more suggestions to decide the direction to fix
> > similar bug. Any thoughts ?
> > 
> > [1]https://bugs.launchpad.net/oslo.config/+bug/1577731
> > [2]http://docs.openstack.org/developer/oslo.config/cfg.html#option-value-interpolation
> > [3]https://review.openstack.org/#/c/338668/
> > 
> > 
> > -- 
> > ChangBo Guo(gcb)
> > 
> > 
> > __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > 
>