Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1691369 - [OSP14] fixes related to multi-attach
Summary: [OSP14] fixes related to multi-attach
Keywords:
Status: ON_QA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-cinder
Version: 14.0 (Rocky)
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: 14.0 (Rocky)
Assignee: Sofia Enriquez
QA Contact: Tzach Shefi
Tana
URL:
Whiteboard:
Depends On: 1661022
Blocks: 1692542
TreeView+ depends on / blocked
 
Reported: 2019-03-21 13:55 UTC by Eric Harney
Modified: 2019-04-16 10:06 UTC (History)
5 users (show)

Fixed In Version: openstack-cinder-13.0.3-2.el7ost
Doc Type: Bug Fix
Doc Text:
Launchpad 1747481 Cause: The attachment creates call was returning HTTP ACCEPTED. However, the response should be a 200 since it's blocking and returns a response body. Consequence: The attachment creates call was returning HTTP ACCEPTED which implies an asynchronous operation. The call shouldn't be async. Fix: The attachment creates call returns SUCCESS instead. Result: The call is sync. ----------------------------------------------------- Launchpad 1783790 Cause: When managing a multi-attach volume under volume type with multi-attach extra spec set to True the multi-attach flag wasn't being set correctly in the volume's properties. Consequence: The multi-attach flag was set to False after a manage operation. Fix: When managing a volume, the API set the multi-attach flag to True inside the volume's properties. Result: Handles the multi-attach attribute when managing existing volumes. ----------------------------------------------------- Launchpad 1790840 Cause: When retyping a multi-attach volume, the multi-attach flag wasn't being set correctly in volume's properties. Consequence: The retype flag was set to False after a manage operation. Fix: The return value of get_by_name_or_id in the volume_types module returns a dictionary. During the function call to _is_multiattach, the getattr() returns {}(default value) because a dictionary is passed instead of an object. After importing the cinder.objects.volume_type module, the current function call to get_by_name_or_id() returns an object hence getattr() will return the appropriate extra_specs instead of the default value({}). Result: Handles the retype attribute when retyping existing volumes. ----------------------------------------------------- Launchpad 1802155 Cause: Before the fix, when migrating attached volumes we thought they were always in "rw" mode, which means that a "ro" attached volume will end up as "rw" after a migration. Consequence: When migrating or retyping with migration a read-only volume, we end up with a read-write volume after the migration. Fix: Set right attach mode after migration Result: When migrating or retyping with migration a read-only volume, instead of a read-write volume, we have a read-only volume. ----------------------------------------------------- Launchpad 1805762 Cause: The Cinder API didn't do any status checks when updating Attachment objects on a Volume. Consequence: API allowed volumes in error state to update attachment records. Fix: API checks volume's status on attachment create/update. Result: This patch adds an explicit check of the volume status in both attachment_create and attachment_update, and if the volume status is in any error state, the call will result in an invalidVolume exception.
Clone Of:
: 1692542 (view as bug list)
Environment:
Last Closed:
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Launchpad 1747481 None None None 2019-03-24 13:21:57 UTC
Launchpad 1783790 None None None 2019-03-24 13:21:57 UTC
Launchpad 1790840 None None None 2019-03-24 13:21:57 UTC
Launchpad 1802155 None None None 2019-03-24 13:21:57 UTC
Launchpad 1805762 None None None 2019-03-24 13:21:57 UTC
OpenStack gerrit 532702 None None None 2019-03-25 23:39:33 UTC
OpenStack gerrit 540972 None None None 2019-03-24 22:03:36 UTC
OpenStack gerrit 613833 None None None 2019-03-24 22:03:36 UTC
OpenStack gerrit 644410 None None None 2019-03-25 23:39:33 UTC
OpenStack gerrit 646043 None None None 2019-03-24 17:35:20 UTC
OpenStack gerrit 646687 None None None 2019-03-24 21:45:48 UTC
OpenStack gerrit 646890 None None None 2019-03-24 22:03:36 UTC

Comment 6 Sofia Enriquez 2019-03-29 19:01:28 UTC
Summary
- No need of backporting Launchpad 532702 and 1790840 as they're already on ops14.
- "Swap volume of multi-attached volume will corrupt data" (Launchpad 1775418) is still on-dev and can't backport because of it.
- We aren't supporting solidfire as part of this backport so I didn't backport    https://review.openstack.org/#/c/641125/ (It will eventually flow into OSP14 as part of a rebase to 13.0.4.)


Note You need to log in before you can comment on or make changes to this bug.