az cdn custom-domain enable-https call is not idempotent

[jonsing]

In our deployment script for our CDN I noticed that executing az cdn custom-domain enable-https will actually re-provision a new certificate and deploy it even though one is already provisioned and deployed.

No big issue for us because I can not see any impact on the existing certificate and the site continues to work normally during the re-provisioning. But it feels unnecessary and I thought all Azure CLI calls where idempotent 😀

We added a check in our script by listing the custom-domains and checking customHttpsProvisioningState and customHttpsProvisioningSubstate which eliminated the re-provisioning every time we ran our bash script.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: ed8c61db-b294-77fb-0e92-eae01d07b776
• Version Independent ID: 958b6e8d-609b-2a58-dbe1-240d3fd894bb
• Content: az cdn custom-domain
• Content Source: src/azure-cli/azure/cli/command_modules/cdn/_help.py
• Service: cdn
• GitHub Login: @rloutlaw
• Microsoft Alias: routlaw

[ghost]

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @aznetsuppgithub, @1VarunCh1, @lsmith130.

[yonzhan]

cdn

[fore5fire]

Unfortunately the CDN service uses a POST for this request and is inherently non-idempotent. We do have plans to fix this in the future, but in the mean time we can add a check to see if the parameters are identical in the CLI command before making the update.

[navba-MSFT]

@jonsing Apologies for the delayed response. We are looking into this issue and will provide an update once we have more details on the fix.

@lsmith130 Could you please let us know if this issue has been fixed ? Awaiting your reply.

[navba-MSFT]

@t-bzhan Please update this github thread once you get a chance.

[t-bzhan]

Ack, looking into that.

[t-bzhan]

As explained earlier in the issue, "az cdn custom-domain enable-https" underlyingly used POST method which is non-idempotent. Adding a check in CLI could not address the issue completely. There stands a chance that the configuration has been changed after the check, it is better solved in service side but that requires much efforts then.

By the way, It seems that idempotency for CLI commands has been discussed a lot and currently no conclusion has been reached regarding to whether a command should be idempotent or not:
#7613
#12786

I will close the issue for now and will stay tuned to CLI team's suggestion for that. If there are more customers asking for that, we might consider to add the implementation.