share continues to be member of group after migration

[Rodrigo Barbieri]

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

[Xing Yang (xing-yang)]

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.

[Rodrigo Barbieri (rodrigo-barbieri2010)]

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.

[OpenStack Infra (hudson-openstack)]

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

[Xing Yang (xing-yang)]

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?

[Rodrigo Barbieri (rodrigo-barbieri2010)]

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.

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

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