share continues to be member of group after migration

Bug #1660319 reported by Rodrigo Barbieri on 2017-01-30
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Manila
High
Rodrigo Barbieri

Bug Description

Steps to reproduce:

At this moment, share groups pertain to certain host, so when migrating shares, share should be moved out of group. Currently, it still says in group showing inconsistent information.

1. create a share group X, should say it is in host W
2. create a share Y in group X
3. migrate the share Y to host Z
4. check fields of the migrated share, it says in host Z but member of group X, which is in host W

Changed in manila:
importance: Undecided → High
milestone: none → ocata-rc1
Xing Yang (xing-yang) wrote :

If a share is in a group, migrate should fail with an error that the share needs to be moved out of the group before migration can happen. A migrate share command should not move share out of the group. It should be a two step process.

If in the future we have a migrate group command, then the group of shares can be moved together.

Xing, it is in the share-groups spec that share migration is the feature that moves shares out of groups. The compability between those 2 features is not ready at this moment, so, ideally, any share migration operation with shares members of groups could be blocked. Although, with CGs, shares could be moved out of groups (and I believe they still can), so an alternative fix could be for the Groups API to detect that a share has been moved out.

Fix proposed to branch: master
Review: https://review.openstack.org/427834

Changed in manila:
assignee: nobody → Rodrigo Barbieri (rodrigo-barbieri2010)
status: New → In Progress
Xing Yang (xing-yang) wrote :

https://review.openstack.org/#/c/315730/12/specs/ocata/manila-share-groups.rst

Migration
---------

Just as some backends may only be able to replicate shares in groups, it
follows that those backends may also need to migrate shares in groups. And in
the case of CGs, it doesn’t make sense to migrate CG members individually; the
whole group must be moved, requiring the migration engine to be CG aware.

The spec says the whole group should be moved and it should not migrate individual share. Am I missing anything?

Xing, from the spec:

Share Groups
------------

Just as Manila has ‘shares’, it should also have ‘share groups’. In its
simplest form, unlike CGs, a share group should not guarantee any specialized
operation. Instead, it should merely constitute an atomic Manila data type on
which nearly any Manila action is available. For example, given a share group,
the user should be able to select the group in the Manila UI and invoke
features such as snapshot, clone, backup, migrate, replicate, retype, etc.
Shares should be able to become a part of a share group only on share creation
step. If share was created without provided "share_group_id" then this share
won't be able to become a part of any share group. To do it, you will need
to use "share migration" feature. If share was created as part of a group, then
it can be moved out of a group only when it is either migrated or deleted.

...

Consistent with CGs, a grouped share must spend its entire lifecycle in the
group. Adding or removing shares from groups at other than creation/deletion
time might be possible for some backends, while others might have to move the
data. The migration engine is envisioned as the means of moving shares into
or out of a group.

Reviewed: https://review.openstack.org/427834
Committed: https://git.openstack.org/cgit/openstack/manila/commit/?id=26c803ea95b7e9b00822a867fc4b9bc04a4f10d4
Submitter: Jenkins
Branch: master

commit 26c803ea95b7e9b00822a867fc4b9bc04a4f10d4
Author: Rodrigo Barbieri <email address hidden>
Date: Wed Feb 1 15:41:03 2017 -0200

    Blocked migration of shares within share groups

    In Ocata, coordination between share migration and share groups
    features was not implemented. So, restrict its usage for now.

    APIImpact

    Change-Id: Id15453590685aa9c7788e79a33ca98b4dcc8a3ea
    Closes-bug: #1660336
    Closes-bug: #1660319

Changed in manila:
status: In Progress → Fix Released

This issue was fixed in the openstack/manila 4.0.0.0rc1 release candidate.

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

Other bug subscribers