#na_ontap_svm module is failing for tasks with vserver(s) of type dp_destination

1 messages · Page 1 of 1 (latest)

crude sage
#

Hi team,

When working with multiple configuration tasks involving dp_destination type versers, if one of the task fails and if try rerunning the config again after fixing the issue, playbook fails while it tries to rerun the vserver create for vserver(s) of type dp_destination.

failed: [localhost] (item={'state': 'present', 'cluster': '10.216.2.57', 'name': 'axasvm01_dr', 'subtype': 'dp_destination'}) => {"ansible_loop_var": "svm", "changed": false, "msg": "Error modifying SVM axasvm01_dr: cannot modify subtype - current: default - desired: dp_destination.", "svm": {"cluster": "10.216.2.57", "name": "axasvm01_dr", "state": "present", "subtype": "dp_destination"}}

I think this is happening because na_ontap_svm is trying to issue a PATCH call against the vserver as it already exists, but PATCH call can't be run for vserver(s) of type dp_destination.

This is impacting idempotancy for our ansible playbooks. So we need either removing vserver creation option or delete the vserver and rerun the config.

Could we please add a status ok and skip the vserver creation job is the vserver type is dp_destination and it already exists?

modest dawn
#

Hi Durai,
Tried to set vserver subtype as default wile creation and tried to modify, as it is not modifiable, it is throwing error as expected.

crude sage
#

Hi Dhivya, with subtype default, I don't see any errors.

ok: [localhost] => (item={'state': 'present', 'cluster': '10.216.2.72', 'name': 'axasvm01', 'subtype': 'default', 'services': {'nfs': {'allowed': True, 'enabled': True}, 'cifs': {'allowed': True}, 'iscsi': {'allowed': False, 'enabled': False}, 'fcp': {'allowed': False, 'enabled': False}, 'ndmp': {'allowed': False}}}) => {"ansible_loop_var": "svm", "changed": false, "svm": {"cluster": "10.216.2.72", "name": "axasvm01", "services": {"cifs": {"allowed": true}, "fcp": {"allowed": false, "enabled": false}, "iscsi": {"allowed": false, "enabled": false}, "ndmp": {"allowed": false}, "nfs": {"allowed": true, "enabled": true}}, "state": "present", "subtype": "default"}}

#

it's always successful with a status "ok" during modify

modest dawn
#

Yes i agree...verified from my end, while creation of vserver we need to provide subtype incase if it is no supplied it will consider that as default subtype, next time if there is a change in subtype then in the beginning itself it is coded like to throw error.
Throwing error is the better option to know what is current subset.
If that error is not required then getting current value has to be reformatted.

crude sage
#

Thanks Divya. But problem point is when we are running multiple configs with automation, our dependency is on the Ansible's idempotent nature.

I understand this error is good to point out it.

But the challenge is while running multiple configs especially in DevOps pipelines if idempotency is not supporting it, its hard to intervene in between as disabling code or config will be code push and pulls which takes considerable time.

modest pendant
crude sage
#

Thats good catch Mohan! I missed it

#

Its not default actual it's a dp-destination. Not sure why it report current is default

#

let me get the logs

crude sage
#

Mohan / Dhivya, unfortunately / fortunately this time I didn't hit this error. I'm not sure if this is intermittent. I will perform my testing with trace_api and keep you updated

crude sage
#

@modest pendant / @modest dawn , Hope you are doing good!

After a while I got this problem reoccured and figured out what was happening. Below are the steps to recreate the issue.

  1. Create vserver of type dp-destination using ansible.
  2. Run an absent of this vserver, but this set the type as default. (I was setting default accidentally in this case)

My understanding was if state absent is set, Ansible module will ignore all other parameters and proceed with vserver remove.

But in above case Ansible was trying to modify the vserver type frpm dp-destination to default causing the error I reported above.

modest pendant
#

we already have a story for this. Ideally module should not check for modify when state is absent.

crude sage
#

In which version this fix will be added?

modest pendant
#

22.6.0

crude sage
#

thanks Mohan!

rain sleet
#

Hello, I experienced an issue with na_ontap_svm module and subtype dp-destination.

I'm trying to automate SVM DR procedure, when I try to start destination vserver with admin_state = running I got this error:

"msg": "Error in modify: calling: svm/svms/95c31f1e-fd6a-11ee-bbc6-d039ea979fee: got {'message': 'Cannot start SVM because it is a dp-destination SVM in an identity-preserve SVMDR relationship.', 'code': '13434921'}."

The vserver successfully starts if I issue 'vserver start' from the CLI.

Collection version: 22.2.0

Thanks for any help

sharp wave
#

Hello, Can you provide the playbook so we can try to replicate the issue?