Ignore comparing protected_settings

[Fred-sun]

SUMMARY

Ignore comparing protected_settings, Try to fixes #473

ISSUE TYPE

• Bugfix Pull Request

COMPONENT NAME

azure_rm_virtualmachineextension.py

ADDITIONAL INFORMATION

[paultaiton]

Howdy @Fred-sun ,

For context, I'm familiar with the bug that prompted this PR, and how the vm extension "resource" works, but am not very knowledgeable about how this module works.

The one concern I have with this modification is how would it work if I need to update a vm extension and the only modification is the protected setting? The specific hypothetical example I can think of is the case of a log-analytics secret key being rotated,
OMS extension
If I need to update a vm to use a new log analytics key, none of the other settings would be modified, so if I'm understanding your code modifications correctly, the module would not recognize that anything changed, and it would just return OK with no modifications being performed in Azure.

This may not be an actual issue in practice. I don't have much experience with rotating keys and updating the extension, so I don't know how it would impact in this specific example, but the general concern would apply to any extension where an update may be made with the only change being a protected setting.

[Fred-sun]

@paultaiton Yes, maybe we should find a way to check the update, I will hold this PR and find a solution, thank you!

[l3ender]

Initial discussion of this issue in Azure/azure_preview_modules#326 mentioned an approach where an additional force_update parameter could be added which would allow a user to re-configure an already installed VM extension. I believe that is a good approach and would help fix this bug.

@Fred-sun I am happy to help work on this issue. Would you mind granting me contributor access to your repo/branch so I can update this PR? Or I can open a separate PR with the new changes built on top of your ones.

Thanks!

[Fred-sun]

@l3ender Invitations have been sent！

[l3ender]

Thanks @Fred-sun!

I have updated the PR. A few notes:

• The CoreOS image is no longer available so I have updated all references to it.
• I used force_update_tag parameter to match SDK property of same name. Since this property applies to more than just the discussed protected_settings parameter, I have updated the module accordingly.
• I added more tests and corrected spec and idempotency.

I ran test cases with the following playbook:

---
- name: "Playbook for testing."
  hosts: "localhost"
  connection: "local"
  gather_facts: false
  vars:
    resource_group: "automated-testing"
    resource_group_secondary: "automated-testing-secondary"
  collections:
    - azure.azcollection

  tasks:
    - name: "Include tests"
      include_tasks: "tests/integration/targets/azure_rm_virtualmachineextension/tasks/main.yml"
      vars:
        protected_settings_file: "tests/integration/targets/azure_rm_virtualmachineextension/files/test-protected-settings.json"
        public_settings_file: "tests/integration/targets/azure_rm_virtualmachineextension/files/test-public-settings.json"

Please take a look and let me know if you have any comments. Thank you!

[l3ender]

Hello @xuzhang3, can you please check on this one? Thank you!

[l3ender]

Hello, any update on this PR? Thank you!

[paultaiton]

I have not looked over the entirety of the PR, but the aproach that @l3ender suggested of a forced-update tag would completely elimanate any of my prior concerns.

[xuzhang3]

@l3ender LGTM shipping it