Open Stack

On 2015-10-14 09:53, Bernd Bausch wrote:
> 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.

v1 exists in Liberty, it has not been removed since many tools only 
support v1 - including other OpenStack projects! See openstack-dev 
mailing lists threads from September,

Andreas

> 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)
>


-- 
  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
    GF: Felix Imendörffer, Jane Smithard, Graham Norton,
        HRB 21284 (AG Nürnberg)
     GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126