Share migration

Registered by Rodrigo Barbieri

Share migration is a feature discussed during Kilo midcycle meetup that proposes being able to move shares from backend to backend.
Upon implementing Share Migration, the Share re-type use case can be implemented, using Migration.
After some study on possible issues when migrating shares, a few limitations have been listed:
- Users will always be disconnected at some point during migration, they will need to remount the share.
- Preferably, a share should be made read-only prior to migration so users can continue using it during migration, this is a reasonable way to deal with huge shares. Changing to read only may cause a disconnect.
- Regarding Share metadata, it may either be chosen to be preserved or not. If chosen to be preserved, the following restrictions apply:
  - Share protocol should not change.
  - Security Services should be taken into account, as moving a Share that relies on a Security Service to another backend may render the Share useless unless the backend is able to register to the same Security Service. For this, Security Services should be advertised in “Capabilities”.

Implementation details:
So far, 2 approaches have been suggested:
1 - delegate to driver: this is a very optimized but restricted approach. The driver may be able to perform migration in a more efficient way if it understands the destination backend. A model update should be returned by the driver after the migration.
2 - managers coordinate, delegates some tasks to drivers: This approach will create a new share on destination host, mount both exports from the manila node, copy all files and then delete the old share. This approach should work for any driver that implements some methods necessary to help the migration process, such as:
  - changing the source share to read-only so users are less impacted by migration.
  - mounting/unmounting exports with specific protocols.

In order for approach 2 to work, every driver during server_setup method must create a port that allows connectivity between the share server and manila node.

Implementation should be a code that attempts approach #1, then #2 if unsuccessful, and should be minimally affected by Driver modes setting.

Blueprint information

Status:
Complete
Approver:
Ben Swartzlander
Priority:
High
Drafter:
Rodrigo Barbieri
Direction:
Approved
Assignee:
Rodrigo Barbieri
Definition:
Discussion
Series goal:
Accepted for liberty
Implementation:
Implemented
Milestone target:
milestone icon 1.0.0
Started by
Ben Swartzlander
Completed by
Clinton Knight

Related branches

Sprints

Whiteboard

Gerrit topic: https://review.openstack.org/#q,topic:share_migration_upstream,n,z

Addressed by: https://review.openstack.org/179790
   Add Share Migration support

Gerrit topic: https://review.openstack.org/#q,topic:bp/share-migration,n,z

Gerrit topic: https://review.openstack.org/#q,topic:share_migration_upstream_dev,n,z

Addressed by: https://review.openstack.org/179791
    Share Migration support in generic driver

Addressed by: https://review.openstack.org/220278
    Add Share Migration tempest functional tests

(?)

Work Items

Work items:
- Add migration call to API: DONE
- Add methods that driver should implement to base driver class: DONE
- Implement migration method in manager: DONE
- Implement copy method: DONE
- Access rule migration: DONE
- "driver_handles_share_servers=false" mode: DONE

This blueprint contains Public information 
Everyone can see this information.

Subscribers

No subscribers.