Open Stack

We already have an environment variable for version... 'auto'?
On 30 Jun 2015 07:57, "John Griffith" <john.griffith8 at gmail.com> wrote:

>
>
> 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?
>
>
> __________________________________________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150630/d93d58bc/attachment.html>