Bug 1030088

We'll have to investigate how this should be implemented.

FWIW devstack does this:

http://git.openstack.org/cgit/openstack-dev/devstack/tree/lib/cinder?id=0a57ae98#n369

The v2 api is enabled by default in RHOS 4.0, tested in a installed openstack using packstack 0.15.dev847.el6

checking out /etc/cinder/cinder.conf

i see:

# Deploy v2 of the Cinder API.  (boolean value)
#enable_v2_api=true

execuing:
OS_VOLUME_API_VERSION=2 cinder --debug list

REQ: curl -i http://192.168.100.170:35357/v2.0/tokens -X POST -H "Content-Type: application/json" -H "Accept: application/json" -H "User-Agent: python-cinderclient" -d '{"auth": {"tenantName": "admin", "passwordCredentials": {"username": "admin", "password": "a7467386308f43f8"}}}'

DEBUG:cinderclient.client:
REQ: curl -i http://192.168.100.170:35357/v2.0/tokens -X POST -H "Content-Type: application/json" -H "Accept: application/json" -H "User-Agent: python-cinderclient" -d '{"auth": {"tenantName": "admin", "passwordCredentials": {"username": "admin", "password": "a7467386308f43f8"}}}'

RESP: [200] {'date': 'Fri, 29 Nov 2013 07:57:48 GMT', 'content-type': 'application/json', 'content-length': '8372', 'vary': 'X-Auth-Token'}
RESP BODY: {"access": {"token": {"issued_at": "2013-11-29T07:57:47.883986", "expires": "2013-11-30T07:57:47Z", "id": "MIIOxAYJKoZIhvcNAQcCoIIOtTCCDrECAQExCTAHBgUrDgMCGjCCDRoGCSqGSIb3DQEHAaCCDQsEgg0HeyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0xMS0yOVQwNzo1Nzo0Ny44ODM5ODYiLCAiZXhwaXJlcyI6ICIyMDEzLTExLTMwVDA3OjU3OjQ3WiIsICJpZCI6ICJwbGFjZWhvbGRlc

... 

<last lines ommited>

It doesn't seem to be a valid bug, and so I'm closing it.
Eric, please, do not hesitate to reopen it if we missed anything.

(In reply to Alvaro Lopez Ortega from comment #4)
Something doesn't seem right here.  I don't see a v2 endpoint, at least running packstack in an upgrade scenario.  (Build is 847.)  I haven't tried a new deployment lately, but it needs to create one when upgrading anyway.

Ivan's output only shows that it hit Keystone v2 for auth... the test here should be that
a) "keystone endpoint-list" has something pointing to :8776/v2/
and b
b) "cinder --debug list"  actually uses that endpoint when OS_VOLUME_API_VERSION=2 is set.

(a) doesn't happen on my machine, and in my test today, (b) fails with "Could not find any suitable endpoint. Correct region?" which makes sense based on the endpoint-list.

"enable_v2_api=True" in cinder.conf just enables it on the server, but that doesn't help anything access it, since it's not in the keystone catalog.

Eric, thanks for the feedback.
Ivan is checking it out again.

Cinder has the api v2 enabled by default, it's keystone the one that does not have the endpoint configured.

I'm making the proper changes to the packstack templates so the v2 endpoint is added to keystone

With: openstack-packstack-2013.2.1-0.14.dev919.el6ost.noarch

# Deploy v2 of the Cinder API.  (boolean value)
#enable_v2_api=true

# keystone endpoint-list | grep 8776

| 64c1c7e3d0534a339712889c6ee7ed0e | RegionOne |   http://192.168.122.97:8776/v1/%(tenant_id)s    |   http://192.168.122.97:8776/v1/%(tenant_id)s    | http://192.168.122.97:8776/v1/%(tenant_id)s | 9ae44956eee94c0b8a19d4d339c5d51b |

# OS_VOLUME_API_VERSION=2 cinder --debug list

...

Could not find any suitable endpoint. Correct region?
ERROR: 

Will retest with .17

With .18:

[root@localhost ~(keystone_admin)]# keystone endpoint-list | grep 8776
| cdca6984077c443c95241ef54f74798d | RegionOne |    http://192.168.122.244:8776/v2/%(tenant_id)s   |    http://192.168.122.244:8776/v2/%(tenant_id)s   | http://192.168.122.244:8776/v2/%(tenant_id)s | ed499b7c7d224170b35d6265be803909 |
| e84145d9fc78434089cccfec3e724b85 | RegionOne |    http://192.168.122.244:8776/v1/%(tenant_id)s   |    http://192.168.122.244:8776/v1/%(tenant_id)s   | http://192.168.122.244:8776/v1/%(tenant_id)s | 1e2d620b70af4136b1f005aa764c595e |

[root@localhost ~(keystone_admin)]# OS_VOLUME_API_VERSION=2 cinder --debug list

RESP: [200] {'date': 'Wed, 11 Dec 2013 21:14:02 GMT', 'x-compute-request-id': 'req-776e8b1e-c6f1-4b58-a083-08060eb60f3a', 'content-type': 'application/json', 'content-length': '15'}
RESP BODY: {"volumes": []}

DEBUG:cinderclient.client:RESP: [200] {'date': 'Wed, 11 Dec 2013 21:14:02 GMT', 'x-compute-request-id': 'req-776e8b1e-c6f1-4b58-a083-08060eb60f3a', 'content-type': 'application/json', 'content-length': '15'}
RESP BODY: {"volumes": []}


[root@localhost ~(keystone_admin)]# echo $?
0

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHEA-2013-1859.html