Open Stack

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/

-- 
Mike Perez