Broken idempotence when using attach_caching on azure_rm_manageddisk

[unkaputtbar112]

SUMMARY

Creating a disk with attach_caching just works fine, however, re-running the same playbook or even changing the attach_caching results in a python error.

AttributeError: module 'azure.mgmt.compute.v2023_04_02.models' has no attribute 'CachingTypes'

ISSUE TYPE

• Bug Report

COMPONENT NAME

azure_rm_manageddisk
azure_rm_common

ANSIBLE VERSION

ansible [core 2.18.1]
  config file = None
  configured module search path = ['/home/<cleaned>/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /home/<cleaned>/azure-test/lib64/python3.12/site-packages/ansible
  ansible collection location = /home/<cleaned>/.ansible/collections:/usr/share/ansible/collections
  executable location = /home/<cleaned>/azure-test/bin/ansible
  python version = 3.12.5 (main, Dec  3 2024, 00:00:00) [GCC 11.5.0 20240719 (Red Hat 11.5.0-2)] (/home/<cleaned>/azure-test/bin/python3.12)
  jinja version = 3.1.5
  libyaml = True

COLLECTION VERSION

[~]$ ansible-galaxy collection list

# /home/almalinux/.ansible/collections/ansible_collections
Collection         Version
------------------ -------
azure.azcollection 3.1.0
community.general  10.2.0

CONFIGURATION

[~]$ ansible-config dump --only-changed
CONFIG_FILE() = None

GALAXY_SERVERS:

OS / ENVIRONMENT

Running on localhost (RHEL 9.4)

STEPS TO REPRODUCE

---
- name: 'test attach caching'
  hosts: localhost
  gather_facts: false
  tasks:
    - name: 'Create managed disk with attach caching'
      azure.azcollection.azure_rm_manageddisk:
        name: '<cleaned-vmname>_DataDisk_attach_caching_0'
        location: 'westeurope'
        resource_group: '<cleaned-rg>'
        create_option: 'empty'
        storage_account_type: 'Premium_LRS'
        disk_size_gb: 256
        attach_caching: 'read_only'
        managed_by: '<cleaned-vmname>'
        zone: 2

EXPECTED RESULTS

To run through, with "OK" on a re-run, as it would not have to change anything, or running through with "Changed" when changing the attach_caching option.

ACTUAL RESULTS

TASK [Create managed disk with attach caching] *******************************************************************************************************************************************
task path: /home/<cleaned>/azure-write-accel.yml:6
<127.0.0.1> ESTABLISH LOCAL CONNECTION FOR USER: <cleaned>
<127.0.0.1> EXEC /bin/sh -c 'echo ~<cleaned> && sleep 0'
<127.0.0.1> EXEC /bin/sh -c '( umask 77 && mkdir -p "` echo /home/<cleaned>/.ansible/tmp `"&& mkdir "` echo /home/<cleaned>/.ansible/tmp/ansible-tmp-1737449354.966851-61150-195253397157764 `" && echo ansible-tmp-1737449354.966851-61150-195253397157764="` echo /home/<cleaned>/.ansible/tmp/ansible-tmp-1737449354.966851-61150-195253397157764 `" ) && sleep 0'
Using module file /home/<cleaned>/.ansible/collections/ansible_collections/azure/azcollection/plugins/modules/azure_rm_manageddisk.py
<127.0.0.1> PUT /home/<cleaned>/.ansible/tmp/ansible-local-61147_1ov4x4c/tmp15nv0k7t TO /home/<cleaned>/.ansible/tmp/ansible-tmp-1737449354.966851-61150-195253397157764/AnsiballZ_azure_rm_manageddisk.py
<127.0.0.1> EXEC /bin/sh -c 'chmod u+x /home/<cleaned>/.ansible/tmp/ansible-tmp-1737449354.966851-61150-195253397157764/ /home/<cleaned>/.ansible/tmp/ansible-tmp-1737449354.966851-61150-195253397157764/AnsiballZ_azure_rm_manageddisk.py && sleep 0'
<127.0.0.1> EXEC /bin/sh -c '/home/<cleaned>/azure-test/bin/python3.12 /home/<cleaned>/.ansible/tmp/ansible-tmp-1737449354.966851-61150-195253397157764/AnsiballZ_azure_rm_manageddisk.py && sleep 0'
<127.0.0.1> EXEC /bin/sh -c 'rm -f -r /home/<cleaned>/.ansible/tmp/ansible-tmp-1737449354.966851-61150-195253397157764/ > /dev/null 2>&1 && sleep 0'
The full traceback is:
Traceback (most recent call last):
  File "/home/<cleaned>/.ansible/tmp/ansible-tmp-1737449354.966851-61150-195253397157764/AnsiballZ_azure_rm_manageddisk.py", line 107, in <module>
    _ansiballz_main()
  File "/home/<cleaned>/.ansible/tmp/ansible-tmp-1737449354.966851-61150-195253397157764/AnsiballZ_azure_rm_manageddisk.py", line 99, in _ansiballz_main
    invoke_module(zipped_mod, temp_path, ANSIBALLZ_PARAMS)
  File "/home/<cleaned>/.ansible/tmp/ansible-tmp-1737449354.966851-61150-195253397157764/AnsiballZ_azure_rm_manageddisk.py", line 47, in invoke_module
    runpy.run_module(mod_name='ansible_collections.azure.azcollection.plugins.modules.azure_rm_manageddisk', init_globals=dict(_module_fqn='ansible_collections.azure.azcollection.plugins.modules.azure_rm_manageddisk', _modlib_path=modlib_path),
  File "<frozen runpy>", line 226, in run_module
  File "<frozen runpy>", line 98, in _run_module_code
  File "<frozen runpy>", line 88, in _run_code
  File "/tmp/ansible_azure.azcollection.azure_rm_manageddisk_payload_msim26g5/ansible_azure.azcollection.azure_rm_manageddisk_payload.zip/ansible_collections/azure/azcollection/plugins/modules/azure_rm_manageddisk.py", line 861, in <module>
  File "/tmp/ansible_azure.azcollection.azure_rm_manageddisk_payload_msim26g5/ansible_azure.azcollection.azure_rm_manageddisk_payload.zip/ansible_collections/azure/azcollection/plugins/modules/azure_rm_manageddisk.py", line 857, in main
  File "/tmp/ansible_azure.azcollection.azure_rm_manageddisk_payload_msim26g5/ansible_azure.azcollection.azure_rm_manageddisk_payload.zip/ansible_collections/azure/azcollection/plugins/modules/azure_rm_manageddisk.py", line 578, in __init__
  File "/tmp/ansible_azure.azcollection.azure_rm_manageddisk_payload_msim26g5/ansible_azure.azcollection.azure_rm_manageddisk_payload.zip/ansible_collections/azure/azcollection/plugins/module_utils/azure_rm_common.py", line 482, in __init__
  File "/tmp/ansible_azure.azcollection.azure_rm_manageddisk_payload_msim26g5/ansible_azure.azcollection.azure_rm_manageddisk_payload.zip/ansible_collections/azure/azcollection/plugins/modules/azure_rm_manageddisk.py", line 655, in exec_module
  File "/tmp/ansible_azure.azcollection.azure_rm_manageddisk_payload_msim26g5/ansible_azure.azcollection.azure_rm_manageddisk_payload.zip/ansible_collections/azure/azcollection/plugins/modules/azure_rm_manageddisk.py", line 847, in is_attach_caching_option_different
AttributeError: module 'azure.mgmt.compute.v2023_04_02.models' has no attribute 'CachingTypes'
fatal: [localhost]: FAILED! => {
    "changed": false,
    "module_stderr": "Traceback (most recent call last):\n  File \"/home/<cleaned>/.ansible/tmp/ansible-tmp-1737449354.966851-61150-195253397157764/AnsiballZ_azure_rm_manageddisk.py\", line 107, in <module>\n    _ansiballz_main()\n  File \"/home/<cleaned>/.ansible/tmp/ansible-tmp-1737449354.966851-61150-195253397157764/AnsiballZ_azure_rm_manageddisk.py\", line 99, in _ansiballz_main\n    invoke_module(zipped_mod, temp_path, ANSIBALLZ_PARAMS)\n  File \"/home/<cleaned>/.ansible/tmp/ansible-tmp-1737449354.966851-61150-195253397157764/AnsiballZ_azure_rm_manageddisk.py\", line 47, in invoke_module\n    runpy.run_module(mod_name='ansible_collections.azure.azcollection.plugins.modules.azure_rm_manageddisk', init_globals=dict(_module_fqn='ansible_collections.azure.azcollection.plugins.modules.azure_rm_manageddisk', _modlib_path=modlib_path),\n  File \"<frozen runpy>\", line 226, in run_module\n  File \"<frozen runpy>\", line 98, in _run_module_code\n  File \"<frozen runpy>\", line 88, in _run_code\n  File \"/tmp/ansible_azure.azcollection.azure_rm_manageddisk_payload_msim26g5/ansible_azure.azcollection.azure_rm_manageddisk_payload.zip/ansible_collections/azure/azcollection/plugins/modules/azure_rm_manageddisk.py\", line 861, in <module>\n  File \"/tmp/ansible_azure.azcollection.azure_rm_manageddisk_payload_msim26g5/ansible_azure.azcollection.azure_rm_manageddisk_payload.zip/ansible_collections/azure/azcollection/plugins/modules/azure_rm_manageddisk.py\", line 857, in main\n  File \"/tmp/ansible_azure.azcollection.azure_rm_manageddisk_payload_msim26g5/ansible_azure.azcollection.azure_rm_manageddisk_payload.zip/ansible_collections/azure/azcollection/plugins/modules/azure_rm_manageddisk.py\", line 578, in __init__\n  File \"/tmp/ansible_azure.azcollection.azure_rm_manageddisk_payload_msim26g5/ansible_azure.azcollection.azure_rm_manageddisk_payload.zip/ansible_collections/azure/azcollection/plugins/module_utils/azure_rm_common.py\", line 482, in __init__\n  File \"/tmp/ansible_azure.azcollection.azure_rm_manageddisk_payload_msim26g5/ansible_azure.azcollection.azure_rm_manageddisk_payload.zip/ansible_collections/azure/azcollection/plugins/modules/azure_rm_manageddisk.py\", line 655, in exec_module\n  File \"/tmp/ansible_azure.azcollection.azure_rm_manageddisk_payload_msim26g5/ansible_azure.azcollection.azure_rm_manageddisk_payload.zip/ansible_collections/azure/azcollection/plugins/modules/azure_rm_manageddisk.py\", line 847, in is_attach_caching_option_different\nAttributeError: module 'azure.mgmt.compute.v2023_04_02.models' has no attribute 'CachingTypes'\n",
    "module_stdout": "",
    "msg": "MODULE FAILURE: No start of json char found\nSee stdout/stderr for the exact error",
    "rc": 1
}

[Fred-sun]

@unkaputtbar112 Fixed in #1808, please try again, thanks!

[unkaputtbar112]

@Fred-sun Thanks for the quick work.

The python issue is fixed, but there are 2 logical issues:

First, the write_accelerator_enabled option seems to only be touched, if the attach_caching changes?
E.g. I run the same playbook, first with:
attach_caching: 'read_only'
and then with both:

attach_caching: 'read_only'
write_accelerator_enabled: True

It will not enable the write accelerator and says "OK" in the task.

Second, if i run the playbook at first with:

attach_caching: 'read_only'
write_accelerator_enabled: True

and then just remove those lines or go with omit and re-run the playbook, it actually changes the attach_caching to None and disables the write accelerator. I would not expect that behaviour, but maybe i'm mistaken?

Sidenote, but nothing that troubles me much: It's rather inconvenient, if for example a user puts in attach_caching: "read_write" and write_accelerator_enabled: True that the disk is unmounted and then the error is told, that this combination is not supported.

[Fred-sun]

@unkaputtbar112 I'm very sorry for replying you so late. We will investigate this issue again after the Spring Festival, thank you!