Description of problem:

OpenStack Manila has support for "managing" and "unmanaging" shares and share snapshots, a valuable workflow for cloud administrators to take shared file systems (and their snapshots) in and out of manila's management. Managing allows manila to adopt/import a share into a configured backend storage system, and apply manila specific extra specifications on it.

Consider for instance a possibility of moving a ceph cluster across OpenStack deployments; or rebuilding an existing OpenStack deployment and registering shares back. It's not trivial for an administrator to remove a share from manila or restore it into manila when performing these day2 cluster maintenance operations. Manila also doesn't support retype operations currently. The alternative to retyping is to migrate shares (which involves an expensive data copy) or to un-manage and re-manage them with a different share type.

Version-Release number of selected component (if applicable): 17

Additional info: The upstream blueprint for this feature is: https://blueprints.launchpad.net/manila/+spec/manage-unmanage-cephfs-shares-and-snapshots

What are the use cases this RFE is solving?

This RFE covers a few scenarios. With this feature, we will be able to allow our customers to easily migrate Ceph Native and NFS shares and snapshots from a 16.2 to a 17 environment, as well as bring shares that already exist to Manila, and then the service will be able to manage the lifecycle of the share.

High Level view on how the feature works

Administrators will able to access the storage and list the existing shares (subvolumes) and their snapshots. If they are managed by another service, or by another version of OpenStack, admins will be able to unmanage them in that service and provide the data to Manila, so Manila will start managing the lifecycle of the shares and snapshots. Manila will be able to control access rules, shrinking, extending and all related actions.

Is this feature driver dependent or driver related?

Yes, this is driver related. The core implementation for this feature is already done, and a couple of backend drivers already offer it.

Are there any known limitations? (e.g multi attach + encryption)

Yes. Usually, when share backends manage shares and snapshots they change the shares' names and the export paths with their Manila identification to ensure they match all other resources managed by Manila. However, this feature is not available in Ceph backends, and we will not be able to rename the shares and snapshots.

Is a CLI change required, does the openstack cmd support it?

No. The core feature is already implemented.

Does this RFE impact / need to be included into the control plane podification?

No.

Does this RFE benefit/impact DCN?

The feature can be used in all environments when implemented, being a great addition.

Does this RFE benefit/impact shift on stack?

The feature can be used in all environments when implemented, being a great addition.

Can this feature be turned on or used in an existing environment?

Only if they upgrade to the newer version where it is implemented. Initially, we don't have the intent to backport this feature, and it will be available in the RHOSO 19 release.

Does this feature affect another DFG or product?

No

Does this feature depend on another RFE?

No

How will the feature affect Upgrades?

It will positively affect upgrades, as the administrators will be able to easily bring their shares and snapshots under Manila management using the manage command. This can make the migrations easier.

How will the feature affect performance or scaling?

No direct impact on performance.

What are the test cases for this RFE?

Managing and unmanaging shares and snapshots and some corner cases. Most scenarios are already implemented, and some possible new scenario tests for cephfs protocol are being discussed and could be implemented.

Are there CI implications?

Yes, mostly enabling the tests scenarios already available in the OpenStack Manila's test suite. And if needed, implementing a few additional test scenarios.

Does it have documentation impact and require early planning with the doc team?

No. Manage/unmanage is already documented, we likely just need to signalize that the CephFS driver will support the feature.

Are there known packaging challenges?

No.

Are there any security considerations?

No.

How much upstream resistance might there be to this feature?

None. The core feature is already implemented. It is okay to have more drivers implementing a core feature.

Will this feature require new or different support skills?

No, only a mention in a GSS KT would be enough.

Will this be required for knowledge transfer to GSS?

It would be nice to share this over a knowledge transfer session to GSS. Support might appreciate knowing that this approach is available, and it will be nice to suggest that customers start using it while migrating their environments, and also bring their shares under Manila's management.

Will this feature impact existing partners or certification programs?

The CephFS drivers will need to run manage/unmanage tests.

API Deprecation/Compatibility?

No.

Are any GUI impact/changes required (Horizon)?

No.