[Openstack-operators] cinder v2 and cinder-client
Jesse Keating
jlk at bluebox.net
Tue Feb 24 19:07:22 UTC 2015
On 2/23/15 10:04 PM, Mike Perez wrote:
> On 23:13 Mon 23 Feb , Fischer, Matt wrote:
>> I’m in the process of trying to cleanup all the deprecations we have after
>> moving some services in Juno. One I have outstanding is this warning about
>> cinder.
>>
>> "The v1 api is deprecated and will be removed after the Juno release. You
>> should set enable_v1_api=false and enable_v2_api=true in your cinder.conf
>> file."
>
> First off thanks for bringing this up. It is something I'm addressing in Kilo.
> I have received feedback from people, that even though v2 has been around since
> Grizzly, people felt the warning being placed in Juno and then removed in the
> next release was not enough time. I agree, and I will actually be removing v1
> support in Liberty. I will start a separate thread announcing this cross list
> in addition to the release notes.
>
>> I played around with this some and I figured out a few things:
>>
>> If you remove the v1 endpoint, cinder client breaks, cinder client breaks
>> because it can’t find the volume service.
>
> Correct, this is because not everyone is moving away from v1, Also since it's
> not EOL, we have to assume some clients are still expecting it. As a result,
> the client's default remains OS_VOLUME_API_VERSION=1, more info on how this
> will change thanks to discovery below.
>
>> If you leave the v1 endpoint, and disable the v1 API, cinder client breaks
>> with "ERROR: ‘volumes’” and the URL its using ends up having /v2/v1 which is
>> obviously wrong.
>>
>> If you remove the v1 endpoint, and disable the v1 API, cinder client breaks
>> because it can’t find the volume service.
>
> Both of these should be fixed by this patch [2], which does version discovery.
> You can see output from manual testing done here [3]. This will be available
> from pypi next month.
>
>> It is possible to pass in an API version to cinder client, but it can’t
>> figure it out on it’s own apparently. I’ve not tried to see how Horizon
>> reacts to this but a broken client is bad enough for me to question this
>> change.
>
> The patch I mentioned earlier will support the previous behavior, and support
> of just setting:
>
> service_type = volume
> endpoint: x.x.x.x:8776
>
> Then from the Cinder client, the default is version 1, so it'll look for v1
> from the Cinder endpoint. If version 2 is explicitly set from the client, it'll
> look for v2.
>
> No need for volumev2. Forget about it.
>
> What the patch doesn't support yet, and I will amend this in, is if no version
> is explicitly set, cinder client will ask keystone what is available, and use
> that as the default. Caching this will be ideal.
>
> If a version is explicitly set, and the server doesn't support it, it'll tell
> you what is available from the server, and to change your explicit set version.
>
>> One option I have is to remove the V1 end point and rename the V2 endpoint to
>> volume (rather than “volumev2”). I think then the client will figure things
>> out. This will break people who have the v1 API in their scripts (and I bet
>> our Icinga stuff might).
>>
>> Another option is to ignore this and assume the client will be fixed.
>>
>> What does everyone else do here?
>
> Without the patch, today users set from the client, OS_VOLUME_API_VERSION=2.
>
> From keystone set:
>
> endpoint: http://x.x.x.x:8776/v2/$(tenant_id)s
> service_type: volumev2
>
>
> [1] - https://wiki.openstack.org/wiki/Releases
> [2] - https://review.openstack.org/#/c/145613/
> [3] - http://paste.openstack.org/raw/155906/
>
Thanks for the input Mike. Do you happen to have any insight into what's
going to happen with python-openstackclient ? As of right now, that tool
set (which is supposed to be the default going forward) doesn't support
cinder v2 in the least. There is no code for it. The individual
python-<service>clients are deprecated (or at least some services are
pushing for its use over the <service>client, see
http://docs.openstack.org/developer/keystone/cli_examples.html ). The
lack of v2 support in openstackclient is a big stumbling block to moving
our stuff over to openstackclient and cinder v2.
--
-jlk
More information about the OpenStack-operators
mailing list