Open Stack

On Mon, Jun 29, 2015 at 11:58 PM, Duncan Thomas <duncan.thomas at gmail.com>
wrote:

> 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
>>
>>
> __________________________________________________________________________
> 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
>
>
​>>​
On Mon, Jun 29, 2015 at 11:58 PM, Duncan Thomas <duncan.thomas at gmail.com>
 wrote:
>>We already have an environment variable for version... 'auto'?
​
Which doesn't work unless you're on current Cinder version, which is what I
thought the whole point of this thread was all about.​  I'm proposing we
actually make sure cinderclient still works with previous versions of
Cinder which IMO is a "real" problem and backporting fixes to I, J, K
releases of Cinder for example doesn't do much good in the case of people
that haven't upgraded yet, or perhaps won't upgrade, and it means they have
to wait for it to release upstream, then their distro to do their testing
and release, and then a patch/update to make it's way to them.

Or:
Revert the change so pip install python-cinderclient just gives them
something that works

Or:
Make the discovery change in the client smart enough to actually just work

Or:
Provide a mechanism and documentation for a user that install the client to
know "hey, this is busted on previous releases, here's how you get around
it"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150630/a5b63258/attachment.html>