openstack
/
manila-specs
Code Issues Proposed changes
manila-specs/specs/caracal/deferred_deletion.rst

4.0 KiB
Raw Blame History

Manila share deferred deletion

Blueprint: https://blueprints.launchpad.net/manila/+spec/deferred-deletion

Manila does not support the deferred deletion of shares. This blueprint is to add support for share deferred deletion. The end user will delete the share using API and then Manila will perform the deferred deletion of the share.

Problem description

If users want to remove a share from Manila, it is possible to delete a given share. The share deletion procedure finishes quickly in manila API service, on the other hand the backend driver takes time. The quota allocated to the share is not freed until share is deleted completely. This increases waiting time for creation of new share. Providing a way to release the quota immediately and perform deferred deletion will solve this issue.

Use Cases

  • The user want to delete multiple shares and then immediately create multiple new shares.
  • The user want to delete share and check the available share and share gigabytes quota.

Proposed change

The following are the changes to be made:

  • A new status values 'DELETING_IN_DRIVER' and 'DELETING_IN_DRIVER_ERROR' will be introduced to identify share instances which will be processed in deferred deletion.
  • Add new configuration option 'deferred_deletion', which means if TRUE the share are deleted in deferred deletion manner else if FALSE the share will be deleted the way it is happening today.
  • As soon as share is deleted, the quota will be reclaimed and share instance will be moved to 'DELETING_IN_DRIVER' state. A periodic task will be added in share manager, which gets all share instances in 'DELETING_IN_DRIVER' state. The share manager then calls backend driver to delete the share instance. Any failure during deletion, will move share instance in the 'DELETING_IN_DRIVER_ERROR' state. User can delete the shares in 'DELETING_IN_DRIVER_ERROR' state, but this time quota will not be reclaimed.
  • No change in backend driver.

Alternatives

Instead of adding new status value, we can mark share as 'DELETED' immediately and move those shares to another project. This project will contain only deleted shares by manila API service. The share manager will run a periodic task to delete share from this project. In this case as well since quota is reclaimed earlier, share manager will make sure share instance must be deleted by backend driver.

An issue with this approach is we will change project id of original share during deletion which can be unwanted data modification.

Data model impact

  • No change in share instance table except introduction of two more values for 'status' field.

CLI API impact

None

REST API impact

None

Driver impact

None

Security impact

None

Notifications impact

None

Other end user impact

If configured, instead of 'deleting' and 'deleting_error' states, end user will now see 'deleting_in_driver' and 'deleting_in_driver_error' states respectively. Also, end user will observe that share in 'deleting_in_driver' state has freed its quota immediately.

The cloud admins can list shares in the new state(s) via API.

Performance Impact

None

Other deployer impact

None

Developer impact

None

Implementation

Assignee(s)

Primary assignee:

Work Items

  • Implement periodic share manager function to process deferred deletion.
  • Implement tempest support.

Future Work Items

None

Dependencies

None

Testing

  • Unit tests
  • Tempest tests

Documentation Impact

  • Docstrings
  • Devref
  • User guide
  • Admin guide
  • Release notes

References

None