Open Stack

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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev