v3 attachment connection_info formatting is different than v2

Bug #1692153 reported by Walt Boring on 2017-05-20
This bug affects 2 people
Affects Status Importance Assigned to Milestone

Bug Description

The v3 attachment_create returns connection_info dict that is formatted different than the v2 initialize_connection dictionary. This data is fed into os-brick which expects booleans to be booleans, not strings, as well as ints to be ints, not strings.

V2 connection_info
{u'data': {u'access_mode': u'rw',
           u'auth_method': u'CHAP',
           u'auth_password': u'csGAiQxXMTjzC6e7',
           u'auth_username': u'5DLFY9BH55AwwjM367sC',
           u'encrypted': False,
           u'qos_specs': None,
           u'target_discovered': False,
           u'target_iqn': u'iqn.2010-10.org.openstack:volume-0306014b-9635-4076-8892-eaef6fa38bd4',
           u'target_lun': 1,
           u'target_portal': u'',
           u'volume_id': u'0306014b-9635-4076-8892-eaef6fa38bd4'},
 u'driver_volume_type': u'iscsi'}

v3 connection_info
{u'attach_mode': None,
 u'attached_at': u'',
 u'connection_info': {u'access_mode': u'rw',
                      u'attachment_id': u'c4d5dfbe-351b-4709-b12a-01a405a2761e',
                      u'auth_method': u'CHAP',
                      u'auth_password': u'csGAiQxXMTjzC6e7',
                      u'auth_username': u'5DLFY9BH55AwwjM367sC',
                      u'driver_volume_type': u'iscsi',
                      u'encrypted': u'False',
                      u'qos_specs': None,
                      u'target_discovered': u'False',
                      u'target_iqn': u'iqn.2010-10.org.openstack:volume-0306014b-9635-4076-8892-eaef6fa38bd4',
                      u'target_lun': u'1',
                      u'target_portal': u'',
                      u'volume_id': u'0306014b-9635-4076-8892-eaef6fa38bd4'},
 u'detached_at': u'',
 u'id': u'c4d5dfbe-351b-4709-b12a-01a405a2761e',
 u'instance': u'b1867679-24e1-4805-aa32-15a7edbe3952',
 u'status': u'reserved',
 u'volume_id': u'0306014b-9635-4076-8892-eaef6fa38bd4'}

As you can see the values in the v3 connection_info is all unicode strings. This breaks checks on encrypted == False, and doing operations on the target_lun which should be an integer, not a unicode string.

Here is the debug mode output from the cinderclient trying to do a local-attach with v2, and v3

DEBUG:keystoneauth:RESP: [200] X-Compute-Request-Id: req-d91d7e33-6e3c-478c-aab9-0980f3087a8e Content-Type: application/json Content-Length: 449 X-Openstack-Request-Id: req-d91d7e33-6e3c-478c-aab9-0980f3087a8e Date: Sat, 20 May 2017 01:56:36 GMT Connection: keep-alive
RESP BODY: {"connection_info": {"driver_volume_type": "iscsi", "data": {"auth_password": "csGAiQxXMTjzC6e7", "target_discovered": false, "encrypted": false, "qos_specs": null, "target_iqn": "iqn.2010-10.org.openstack:volume-0306014b-9635-4076-8892-eaef6fa38bd4", "target_portal": "", "volume_id": "0306014b-9635-4076-8892-eaef6fa38bd4", "target_lun": 1, "access_mode": "rw", "auth_username": "5DLFY9BH55AwwjM367sC", "auth_method": "CHAP"}}}

RESP BODY: {"attachment": {"status": "reserved", "detached_at": "", "connection_info": {"access_mode": "rw", "attachment_id": "c4d5dfbe-351b-4709-b12a-01a405a2761e", "target_discovered": "False", "encrypted": "False", "driver_volume_type": "iscsi", "qos_specs": null, "target_iqn": "iqn.2010-10.org.openstack:volume-0306014b-9635-4076-8892-eaef6fa38bd4", "target_portal": "", "volume_id": "0306014b-9635-4076-8892-eaef6fa38bd4", "target_lun": "1", "auth_password": "csGAiQxXMTjzC6e7", "auth_username": "5DLFY9BH55AwwjM367sC", "auth_method": "CHAP"}, "attached_at": "", "attach_mode": null, "instance": "b1867679-24e1-4805-aa32-15a7edbe3952", "volume_id": "0306014b-9635-4076-8892-eaef6fa38bd4", "id": "c4d5dfbe-351b-4709-b12a-01a405a2761e"}}

Walt Boring (walter-boring) wrote :

Digging a bit deeper, it looks like this is being caused by using the Oslo versioned objects type
DictOfStringsField. That forces every single value to a string, which changes the formatting to include quotes for values, where they didn't exist previously.

Here is our declaration of the usage.

Oslo's object.

Matt Riedemann (mriedem) wrote :

This will have to be dealt with on the client side, you can't change the response now that it's in the API and exposed. To change this in the response again, you'd have to do it in a new microversion.

Hanxi Liu (hanxi-liu) wrote :

I saw the code changed to fix the same issue.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers