Open Stack

Sorry, I don't think I was entirely clear with my proposal - I meant that
we release a new current that will default to the old behavior, but allow
the new behavior to be tested by explicitly choosing the value 'auto'. This
allows people to test their config with version discovery, without breaking
normal usage.
On 30 Jun 2015 19:28, "John Griffith" <john.griffith8 at gmail.com> wrote:

>
>
> 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"
>
>
>
>
> __________________________________________________________________________
> 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/477c68a3/attachment.html>