[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.


More information about the OpenStack-operators mailing list