We already have an environment variable for version... 'auto'? On 30 Jun 2015 07:57, "John Griffith" <john.griffi...@gmail.com> wrote:
> > > On Mon, Jun 29, 2015 at 8:54 PM, Jay Bryant <jsbry...@electronicjungle.net > > wrote: > >> I too would prefer option 2. Would rather do the pack ports than remove >> the functionality. >> >> Jay >> >> On Wed, Jun 24, 2015 at 9:40 AM Gorka Eguileor <gegui...@redhat.com> >> wrote: >> >>> On Tue, Jun 23, 2015 at 08:49:55AM -0700, Mike Perez wrote: >>> > There was a bug raised [1] from some large deployments that the Cinder >>> > client 1.2.0 and beyond is not working because of version discovery. >>> > Unfortunately it's not taking into account of deployments that have a >>> > proxy. >>> >>> A little bit unrelated, but volume pagination in Cinder client is also >>> broken due to Version Discovery: >>> https://bugs.launchpad.net/python-cinderclient/+bug/1453755 >>> >>> > >>> > Cinder client asks Keystone to find a publicURL based on a version. >>> > Keystone will gather data from the service catalog and ask Cinder for >>> > a list of the public endpoints and compare. For the proxy cases, >>> > Cinder is giving internal URLs back to the proxy and Keystone ends up >>> > using that instead of the publicURL in the service catalog. As a >>> > result, clients usually won't be able to use the internal URL and >>> > rightfully so. >>> > >>> > This is all correctly setup on the deployer's side, this an issue with >>> > the server side code of Cinder. >>> > >>> > There is a patch that allows the deployer to specify a configuration >>> > option public_endpoint [2] which was introduced in a patch in Kilo >>> > [3]. The problem though is we can't expect people to already be >>> > running Kilo to take advantage of this, and it leaves deployers >>> > running stable releases of Juno in the dark with clients upgrading and >>> > using the latest. >>> > >>> > Two options: >>> > >>> > 1) Revert version discovery which was introduced in Kilo for Cinder >>> client. >>> > >>> > 2) Grant exception on backporting [4] a patch that helps with this >>> > problem, and introduces a config option that does not change default >>> > behavior. I'm also not sure if this should be considered for Icehouse. >>> >>> +1 to option 2 and I wouldn't be totally against considering it for >>> Icehouse. >>> >>> Cheers, >>> Gorka. >>> > >>> > >>> > [1] - https://launchpad.net/bugs/1464160 >>> > [2] - >>> http://docs.openstack.org/kilo/config-reference/content/cinder-conf-changes-kilo.html >>> > [3] - https://review.openstack.org/#/c/159374/ >>> > [4] - https://review.openstack.org/#/c/194719/ >>> > >>> > -- >>> > Mike Perez >>> > >>> > >>> __________________________________________________________________________ >>> > OpenStack Development Mailing List (not for usage questions) >>> > Unsubscribe: >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> 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. > > 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? > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
