Open Stack

On Mon, Jun 29, 2015 at 8:54 PM, Jay Bryant <jsbryant at 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 <geguileo at 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-request at 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-request at 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-request at 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150629/e75b2a09/attachment.html>