Open Stack

A high priority documentation bug about deprecation/obsolescence of Cinder API v1 is still open. Deprecation is already documented, so that nothing has to be fixed there. See https://bugs.launchpad.net/openstack-manuals/+bug/1366184.

 

I was under the impression that v1 would be removed from Liberty, which would require additional changes to the documentation. According to the recent email thread about Cinder API versions, however, v1 continues to exist.

 

Can you confirm that v1 does indeed exist in Liberty? If so, I think this bug can be closed without further work.

 

Bernd.

 

From: Matt Kassawara [mailto:mkassawara at gmail.com] 
Sent: Wednesday, October 14, 2015 1:22 AM
To: Thomas Goirand <zigo at debian.org>
Cc: Andreas Jaeger <aj at suse.com>; openstack-docs at lists.openstack.org
Subject: Re: [OpenStack-docs] [install-guide] Cinder service and endpoint: v1 or v2? [was: status of Debian]

 

I'm not seeing any problems with the magic combination in Liberty, nor did it generate any bugs in the Kilo version of the installation guide. So, I'll probably just restore the magic combination in the Liberty version of the installation guide and keep an eye on the bugs.

 

On Tue, Oct 13, 2015 at 10:05 AM, Thomas Goirand <zigo at debian.org <mailto:zigo at debian.org> > wrote:

On 10/13/2015 04:57 PM, Matt Kassawara wrote:
> Without straying too far off-topic, the v1/v2 issues with cinder cause
> major headaches for the installation guide primarily because we can't
> get a consistent answer from the developers regarding the appropriate
> service entities and API endpoints.

IMO, don't trust what they say, and try by yourself.

> Furthermore, the gates often contain
> defunct configuration.

The gate tests things with pip, it's not a packaged environment, and
therefore, shouldn't be considered the holy truth either.

> For Kilo, I spent probably too much time finding
> a magic combination that worked for the conventional cinder client,
> OpenStack client, and nova. I found one... two service entities,
> cinder/volume and cinderv2/volumev2 with API endpoints that all contain
> /v2.

Well, I tried that with Liberty, and it didn't work. I was very
surprised to read that the install-guide for Kilo recommends setting-up
a /v2 URL for the v1 API (it really doesn't make sense...). From my
experience, this is broken. What needs to be done is:
- name:cinder type:volume url:/v1/%(tenant_id)s <url://v1/%25(tenant_id)s> 
- name:cinderv2 type:volumev2 url:/v2/%(tenant_id)s <url://v2/%25(tenant_id)s> 

I'm not entirely sure for Kilo, but for Liberty, I'm positive that this
is what should be done. With any other type of setup, there's some
tempest failures on my CI.

> As with every release, I attempted to determine the recommendations
> for Liberty which seem to involve removing the cinder/volume service
> entity and endpoints that contain /v1.

Nope. I had functional test failures with that...

> The recommendations work for what
> the installation guide needs to accomplish. However, they break the
> OpenStack client. Frankly, the only real solution to these perpetual
> problems involves cinder (including services that use it) and clients
> supporting one cinder/volume service entity and endpoints without a
> specific version in them.

What needs to happen is cinder-api v2 to support all what's in v1. But
as of Liberty rc2, we're not there yet, unfortunately.

Cheers,

Thomas Goirand (zigo)

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20151014/ff521313/attachment-0001.html>