na_ontap_snapmirror failing with a REST job timeout

[lapis tulip]

Hi everyone - question about na_ontap_snapmirror failing with a REST job timeout

I’m creating an SVM-DR relationship with the Ansible module netapp.ontap.na_ontap_snapmirror using REST. The task fails even though the relationship ends up in snapmirrored and the transfer completes.

Env (let me know if you need more):

• ONTAP: 9.16.1P8
• netapp.ontap collection: 22.14.0

Playbook snippet:

- name: Configure SnapMirror (SVM-DR)
  netapp.ontap.na_ontap_snapmirror:
    state: present
    source_endpoint:
      path: "{{ vserver_name + ':' }}"
    destination_endpoint:
      path: "{{ dr_vserver_name + ':' }}"
    policy: "NVS_MirrorAndVault_Skip_Net"
    identity_preservation: "exclude_network_config"
    initialize: true
    update: true
    relationship_state: active
    hostname: "{{ dr_cluster_fqdn }}"
    username: "{{ dr_username }}"
    password: "{{ dr_password }}"
    https: true
    validate_certs: true
    use_rest: Always

Error returned by the module (AAP output):

Error patching SnapMirror: {'state': 'snapmirrored'}; job reported error:
Timeout error: Process still running, received {'job': {'uuid': 'd7f3aeb9-beff-11f0-9513-d039ea129b17',
'_links': {'self': {'href': '/api/cluster/jobs/d7f3aeb9-beff-11f0-9513-d039ea129b17'}}}}

[lapis tulip]

the cluster is quite big:

• 2500 vols
• 150 SVM-DR relationships
• 10 Nodes (A400 and C800)

[hardy tulip]

@lapis tulip Could you please update the latest collection and try creating the snapmirror relationship with transferring_time_out option.
If issue persists please share the complete log
https://github.com/ansible-collections/netapp.ontap/wiki/Debugging#tracing-zapi-and-rest-api-calls

[lapis tulip]

It seems that this is an Ontap job timeout, not an issue with waiting for snapmirrored and healty. The transferring_time_out is set to 300 seconds by default, and the job is failing much sooner.

[hardy tulip]

Could you please share the logs

[lapis tulip]

I will share them, but since it's production, it has to go through a formal process, which will take some time.

[lapis tulip]

Hi @hardy tulip

Here's the log. I'd appreciate your help.

[hardy tulip]

@lapis tulip Thanks for the log, Checking from our end.

[hardy tulip]

Story DEVOPS-8097 created to increase timeout seconds.

[lapis tulip]

Thanks! It might be worth adding a parameter to make the timeout configurable. Especially for heavily loaded clusters scenario, it might make sense to let customers choose the timeout themselves, since NetApp doesn’t really know how busy a given cluster is.

Since you’ve created a story for this, could you let me know what the next steps are and roughly when a fix might be expected?