Open Stack

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.

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".

> 
> 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
>