<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<div class="">All,</div>
<div class=""><br class="">
</div>
<div class="">I created a patch that would introduce a new behavior in how oslo.config matches StrOpt choice values.</div>
<div class=""><br class="">
</div>
<a href="https://review.openstack.org/#/c/167025/" class="">https://review.openstack.org/#/c/167025/</a>
<div class=""><br class="">
</div>
<div class="">I’m emailing the mailing list to get a consensus on whether the approach is the correct one. </div>
<div class=""><br class="">
</div>
<div class="">Historically oslo.config matches given StrOpt values to choices in a case sensitive manner. But this patch would make that match case insensitive. This should make it slightly easier for deployers so they don’t have to worry about specifying
the correct capitalization. But the drawback is that this change will not allow having choices with the same characters but different capitalization. </div>
<div class=""><br class="">
</div>
<div class="">For example (this would not be allowed): </div>
<div class=""><br class="">
</div>
<div class="">cfg.StrOpt(‘foo_opt’,</div>
<div class=""> choices=(‘FOO’, ‘foo’)</div>
<div class=""> help=‘blah’)</div>
<div class=""><br class="">
</div>
<div class="">I doubt we have any cases of above, but correct me if I’m wrong.</div>
<div class=""><br class="">
</div>
<div class="">Another suggested alternative was to have a new flag on StrOpt to specify whether the matching is case sensitive or insensitive. This avoids the issue above, but means the deployer must take note of whether the option is case insensitive or insensitive.</div>
<div class=""><br class="">
</div>
<div class="">Let me know your thoughts. Thanks<br class="">
<div class=""><br class="">
</div>
</div>
</body>
</html>