<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 29, 2015 at 11:58 PM, Duncan Thomas <span dir="ltr"><<a href="mailto:duncan.thomas@gmail.com" target="_blank">duncan.thomas@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><p dir="ltr">We already have an environment variable for version... 'auto'?</p><div class=""><div class="h5">
<div class="gmail_quote">On 30 Jun 2015 07:57, "John Griffith" <<a href="mailto:john.griffith8@gmail.com" target="_blank">john.griffith8@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div style="font-family:monospace,monospace"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 29, 2015 at 8:54 PM, Jay Bryant <span dir="ltr"><<a href="mailto:jsbryant@electronicjungle.net" target="_blank">jsbryant@electronicjungle.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>I too would prefer option 2.  Would rather do the pack ports than remove the functionality.<span><font color="#888888"><br><br>Jay</font></span></div><div><div><br><div class="gmail_quote"><div dir="ltr">On Wed, Jun 24, 2015 at 9:40 AM Gorka Eguileor <<a href="mailto:geguileo@redhat.com" target="_blank">geguileo@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">On Tue, Jun 23, 2015 at 08:49:55AM -0700, Mike Perez wrote:<br>
> There was a bug raised [1] from some large deployments that the Cinder<br>
> client 1.2.0 and beyond is not working because of version discovery.<br>
> Unfortunately it's not taking into account of deployments that have a<br>
> proxy.<br>
<br>
A little bit unrelated, but volume pagination in Cinder client is also<br>
broken due to Version Discovery:<br>
<a href="https://bugs.launchpad.net/python-cinderclient/+bug/1453755" rel="noreferrer" target="_blank">https://bugs.launchpad.net/python-cinderclient/+bug/1453755</a><br>
<br>
><br>
> Cinder client asks Keystone to find a publicURL based on a version.<br>
> Keystone will gather data from the service catalog and ask Cinder for<br>
> a list of the public endpoints and compare. For the proxy cases,<br>
> Cinder is giving internal URLs back to the proxy and Keystone ends up<br>
> using that instead of the publicURL in the service catalog. As a<br>
> result, clients usually won't be able to use the internal URL and<br>
> rightfully so.<br>
><br>
> This is all correctly setup on the deployer's side, this an issue with<br>
> the server side code of Cinder.<br>
><br>
> There is a patch that allows the deployer to specify a configuration<br>
> option public_endpoint [2] which was introduced in a patch in Kilo<br>
> [3]. The problem though is we can't expect people to already be<br>
> running Kilo to take advantage of this, and it leaves deployers<br>
> running stable releases of Juno in the dark with clients upgrading and<br>
> using the latest.<br>
><br>
> Two options:<br>
><br>
> 1) Revert version discovery which was introduced in Kilo for Cinder client.<br>
><br>
> 2) Grant exception on backporting [4] a patch that helps with this<br>
> problem, and introduces a config option that does not change default<br>
> behavior. I'm also not sure if this should be considered for Icehouse.<br>
<br>
+1 to option 2 and I wouldn't be totally against considering it for<br>
Icehouse.<br>
<br>
Cheers,<br>
Gorka.<br>
><br>
><br>
> [1] - <a href="https://launchpad.net/bugs/1464160" rel="noreferrer" target="_blank">https://launchpad.net/bugs/1464160</a><br>
> [2] - <a href="http://docs.openstack.org/kilo/config-reference/content/cinder-conf-changes-kilo.html" rel="noreferrer" target="_blank">http://docs.openstack.org/kilo/config-reference/content/cinder-conf-changes-kilo.html</a><br>
> [3] - <a href="https://review.openstack.org/#/c/159374/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/159374/</a><br>
> [4] - <a href="https://review.openstack.org/#/c/194719/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/194719/</a><br>
><br>
> --<br>
> Mike Perez<br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div>
</div></div><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><div style="font-family:monospace,monospace">​I'll echo Jeremy and Dave's statements regarding compatibility, seems really pretty lame that this can't work.  If it's not possible to support both scenarios in the client in a reasonable manner without long timeout periods my vote is for a revert and new client version. Sorry, but in my opinion backports to Cinder itself don't cut it in this case.  It's unfortunate we got to this point.  </div><div style="font-family:monospace,monospace"><br></div><div style="font-family:monospace,monospace">Why can't we make this a config option in cinderclient itself?  Like "USE_AUTO_DISCOVERY=True|False" with a default of False in the client and just deal with it or as others have asked can't we make all of this "smarter"?  I mean it's sort of odd to have a discovery option that only works with 'new' versions of the API doesn't it?</div><br></div></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div>
</div></div><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote><div> </div></div><div class="gmail_default" style="font-family:monospace,monospace;display:inline">​>>​</div>On Mon, Jun 29, 2015 at 11:58 PM, Duncan Thomas <span dir="ltr"><<a href="mailto:duncan.thomas@gmail.com" target="_blank">duncan.thomas@gmail.com</a>></span> wrote:<br><div class="gmail_default" style="font-family:monospace,monospace"><span style="font-family:arial,sans-serif;font-size:small">>>We already have an environment variable for version... 'auto'?</span></div><div class="gmail_default" style="font-family:monospace,monospace">​</div><div class="gmail_default" style="font-family:monospace,monospace">Which doesn't work unless you're on current Cinder version, which is what I thought the whole point of this thread was all about.​  I'm proposing we actually make sure cinderclient still works with previous versions of Cinder which IMO is a "real" problem and backporting fixes to I, J, K releases of Cinder for example doesn't do much good in the case of people that haven't upgraded yet, or perhaps won't upgrade, and it means they have to wait for it to release upstream, then their distro to do their testing and release, and then a patch/update to make it's way to them.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Or:</div><div class="gmail_default" style="font-family:monospace,monospace">Revert the change so pip install python-cinderclient just gives them something that works</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Or:</div><div class="gmail_default" style="font-family:monospace,monospace">Make the discovery change in the client smart enough to actually just work</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Or:</div><div class="gmail_default" style="font-family:monospace,monospace">Provide a mechanism and documentation for a user that install the client to know "hey, this is busted on previous releases, here's how you get around it"</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><br></div></div>