<div dir="ltr"><div><div>Does your project use option value interpolation ? As I know, nova use it.<br></div>we also disccussed in oslo team, should we deprecate this feature ?<br></div>Any thoughts ?<br><div><div><div><div><br><div><div><div><div class="gmail_extra"><div class="gmail_quote">2016-07-08 22:14 GMT+08:00 ChangBo Guo <span dir="ltr"><<a href="mailto:glongwave@gmail.com" target="_blank">glongwave@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div>Hi ALL,<br><br></div>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].  <br><p>copy of Doug Hellmann's coments:</p><p>"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).</p><p>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).</p><p>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.</p><p>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." <br></p></div>I would like to collect more suggestions to decide the direction to fix similar bug. Any thoughts ?<br><br>[1]<a href="https://bugs.launchpad.net/oslo.config/+bug/1577731" target="_blank">https://bugs.launchpad.net/oslo.config/+bug/1577731</a><br>[2]<a href="http://docs.openstack.org/developer/oslo.config/cfg.html#option-value-interpolation" target="_blank">http://docs.openstack.org/developer/oslo.config/cfg.html#option-value-interpolation</a><br>[3]<a href="https://review.openstack.org/#/c/338668/" target="_blank">https://review.openstack.org/#/c/338668/</a><span class=""><font color="#888888"><br><br clear="all"><div><div><div><div><br>-- <br><div data-smartmail="gmail_signature"><div dir="ltr"><div>ChangBo Guo(gcb)</div></div></div>
</div></div></div></div></font></span></div>
</blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>ChangBo Guo(gcb)</div></div></div>
</div></div></div></div></div></div></div></div></div>