access_mode not set properly in connection_info via attachment_update

[Matt Riedemann]

This is purely based on code inspection, but when calling attachment_update with mode='ro' in the host connector, the volume manager first gets the connection_info dict:

https://github.com/openstack/cinder/blob/f01ae575da949af53734645839c9fda2f67a10b2/cinder/volume/manager.py#L4375

Which relies on the attached_mode from the volume admin metadata:

https://github.com/openstack/cinder/blob/f01ae575da949af53734645839c9fda2f67a10b2/cinder/volume/manager.py#L1612-L1620

But attachment_update doesn't set the volume admin metadata until after getting the connection_info:

https://github.com/openstack/cinder/blob/f01ae575da949af53734645839c9fda2f67a10b2/cinder/volume/manager.py#L4382

It also looks like access_mode is stored globally on the volume via the admin metadata rather than per-attachment, which is likely a problem because I could do something like:

* create read/write volume (default)
* attach read-write attachment via attachments API
* attach read-only attachment via attachments API
* now the volume admin metadata attach_mode is marked as read-only even though the default attach mode is read/write, so all subsequent attachments to the volume are going to be read-only

But that's likely a separate bug.

[Matt Riedemann (mriedem)]

Also, here is an example of a read-only volume attachment where the connection_info says the access_mode is 'rw' but the attachment shows the attach_mode='ro':

http://logs.openstack.org/90/572790/6/check/nova-multiattach/a1c6b26/logs/screen-n-api.txt.gz#_Jun_06_23_08_15_201532

{
   "attachment":{
      "status":"attached",
      "detached_at":"",
      "connection_info":{
         "auth_password":"jA5qkRgKkfEWXYSp",
         "attachment_id":"18d5e902-f509-48ed-91fe-29cb4a893f7c",
         "target_discovered":false,
         "encrypted":false,
         "driver_volume_type":"iscsi",
         "qos_specs":null,
         "target_iqn":"iqn.2010-10.org.openstack:volume-c430ddbc-aa1a-4e7d-8914-961e193bc42a",
         "target_portal":"104.239.135.61:3260",
         "volume_id":"c430ddbc-aa1a-4e7d-8914-961e193bc42a",
         "target_lun":1,
         "access_mode":"rw",
         "auth_username":"Nt3XB76dNPTBrTHBaddF",
         "auth_method":"CHAP"
      },
      "attached_at":"2018-06-06T23:08:14.000000",
      "attach_mode":"ro",
      "instance":"7e21dad7-3ca1-405b-b70b-1a2e1f80d83c",
      "volume_id":"c430ddbc-aa1a-4e7d-8914-961e193bc42a",
      "id":"18d5e902-f509-48ed-91fe-29cb4a893f7c"
   }
}

[TommyLike (hu-husheng)]

Also there are several similar concepts that would confuse people who doesn't have the full background of the attach_mode stuff:

1. cinder volume driver will return 'access_mode' in connection info
2. we have 'attached_mode' set in volume admin metadata.
3. There would be a 'readonly' flag in the volume admin metadata as well.
4. User can specify the 'mode' when create/update the attachment.
5. Object attachment also keeps the attribute 'attach_mode'.

What's the relationship of these :(..