na_elementsw_volume should allow for the option to not automatically purge a volume on delete

[kpapreck]

SUMMARY

When deleting a Volume in Element OS, it will first put it in a Deleted Volumes Queue for 8 hours. After 8 hours, the volume will automatically be purged. This is allow for recovery of accidental deletions. The current task: Delete Volume is currently written to automatically purge the volume.

I am suggesting adding purge as an option. I fixed the python code to reflect it and it is working as expected. Please see the updated code and reach out if you have any questions.

ISSUE TYPE

• Feature Idea

COMPONENT NAME

netapp.elementsw.na_elementsw_volume
https://github.com/ansible-collections/netapp/blob/main/ansible_collections/netapp/elementsw/plugins/modules/na_elementsw_volume.py

Modified code that adds the purge option:
https://github.com/kpapreck/ansible-sf/blob/master/na_elementsw_volume.py

ADDITIONAL INFORMATION

Feature usage is to keep the default as to automatically purge to not affect any current customer workflows of deleting volumes if they are looking to immediately delete accounts afterwards, as while the volume resides in Deleted Volumes for 8 hours, they will not be able to delete the account. It will then be written as an optional parameter in case they want to skip the purge.

Today the deleted volume task runs with this example:

• name: Delete Volume
  na_elementsw_volume:
  hostname: "{{ elementsw_hostname }}"
  username: "{{ elementsw_username }}"
  password: "{{ elementsw_password }}"
  state: absent
  name: AnsibleVol
  account_id: 2

My version will allow for the Delete volume to also accept the optional purge flag, where False: will keep the volume under the deleted volumes for 8 hours. purge: True will automatically purge it on delete. Not having the variable will assume purge: True (as it is today).

• name: Delete Volume without purge
  na_elementsw_volume:
  hostname: "{{ elementsw_hostname }}"
  username: "{{ elementsw_username }}"
  password: "{{ elementsw_password }}"
  state: absent
  name: AnsibleVol
  account_id: 2
  purge: False

Code changes adds:
self.argument_spec.update(dict(
purge=dict(required=False, default='True',
choices=['False', 'True'], type='str'),

set up state variables

self.purge = param['purge']

def delete_volume(self, volume_id):
"""
Delete and purge the volume using volume id
:return: Success : True , Failed : False
"""
options = dict(
purge=self.purge,
)
if self.purge is not None:
options['purge'] = self.purge
try:
self.sfe.delete_volume(volume_id=volume_id)
#if self.purge is not None:
if self.purge == "True":
self.sfe.purge_deleted_volume(volume_id=volume_id)
# Delete method will delete and also purge the volume instead of moving the volume state to inactive.

    except Exception as err:
        # Throwing the exact error message instead of generic error message
        self.module.fail_json(msg='Error deleting volume: %s, %s' % (str(volume_id), to_native(err)),
                              exception=to_native(err))

Modified version of code is here:
https://github.com/kpapreck/ansible-sf/blob/master/na_elementsw_volume.py

[lonico]

What is the use case for this? When doing manual operations, it makes sense to provide a 'undo' option. But when doing automation, we would expect actions to be thought through.

[scaleoutsean]

I agree with both of you - it's true that usually people just want to Purge-on-Delete, but I think it'd be nice to have the ability to override this behavior while keeping Purge as default volume delete option.

If one builds a workflow for Ops that's Ansible Tower-driven, it's almost like a UI, and I'd tend to enable Recycle Bin (disable auto-Purge) for volumes deleted in such workflows because people can pick a wrong volume from a drop-down list or key in wrong volume ID.

It could also be said that Ansible in general follows Element API defaults, but in this case it does not; Purge-on-Delete isn't default behavior in Element (and that makes sense; when volumes are created and deleted in numbers, we don't want them to pile up in Recycle Bin - Trident does the same).
While the current behavior is non-standard as far as API defaults go, having the ability to override it would help in automation scenarios when Restore can be helpful.