Bug 1041421

Summary: [RFE][nova]: Nova support cinder client v2
Product: Red Hat OpenStack Reporter: RHOS Integration <rhos-integ>
Component: openstack-novaAssignee: RHOS Maint <rhos-maint>
Status: CLOSED CURRENTRELEASE QA Contact: Sean Toner <stoner>
Severity: high Docs Contact:
Priority: medium    
Version: unspecifiedCC: markmc, ndipanov, rhos-maint, sgordon, stoner, yeylon
Target Milestone: gaKeywords: FutureFeature, Triaged, Upstream
Target Release: 6.0 (Juno)   
Hardware: Unspecified   
OS: Unspecified   
URL: https://blueprints.launchpad.net/nova/+spec/support-cinderclient-v2
Whiteboard: upstream_milestone_juno-3 upstream_status_implemented upstream_definition_approved
Fixed In Version: openstack-nova-2014.2.1-11.el7ost Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-02-09 20:04:54 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description RHOS Integration 2013-12-12 16:03:53 UTC
Cloned from launchpad blueprint https://blueprints.launchpad.net/nova/+spec/support-cinderclient-v2.

Description:

Now nova only support cinder client v1 by default, from nova/volume/cinder, it just import cinderclient.v1 as cinderclient. Since cinder have v1 and v2 client, we need add code for nova support cinder v2 client. 

The blueprint also fix bug 1215772 -- Nova Attach/Detach Volume can't work if volume endpoint set to v2

Specification URL (additional information):

None

Comment 2 Sean Toner 2014-09-04 14:21:46 UTC
The blueprint states:

"Making these changes to the wrapper won't require any change to its interface
or changes to how it returns information. This is done by the wrapper doing the
translation and still giving back the expected data structure as it would with
v1."

If this is so, how do I verify that the actual v2 api was issued as opposed to the old v1?

Comment 3 Sean Toner 2014-09-16 15:25:22 UTC
Please see comment 2

It's unclear to me from the blueprint how to verify that the v2 api was issued instead of the v1 api

Comment 4 Russell Bryant 2014-09-16 17:44:13 UTC
(In reply to Sean Toner from comment #3)
> Please see comment 2
> 
> It's unclear to me from the blueprint how to verify that the v2 api was
> issued instead of the v1 api

For testing, I would just execute a general nova+cinder regression test.  Make sure attaching/detaching volumes still works.  Make sure boot from volume still works ... tempest should cover all of this.

If v1 is used, the following warning will be in the nova logs:

                msg = _LW('Cinder V1 API is deprecated as of the Juno '
                          'release, and Nova is still configured to use it. '
                          'Enable the V2 API in Cinder and set '
                          'cinder_catalog_info in nova.conf to use it.')

You could also try enabling debug in cinder-api to see if that makes it clear which API is being hit.

A brute force way to check would be to do a packet capture on the cinder-api node and look at the HTTP requests in wireshark.

I'd say the key things we want to check here are:

1) Nova+Cinder integration still works (tempest all passes)

2) Our deployment tools deploy Cinder with v2 on by default and that Nova uses it

Comment 6 Scott Lewis 2015-02-09 20:04:54 UTC
This bug has been closed as a part of the RHEL-OSP 6 general availability release. For details, see https://rhn.redhat.com/errata/rhel7-rhos-6-errata.html