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
