[DO NOT MERGE] cdn new version 2022 01 01 preview

[priyadmurugan]

MSFT employees can try out our new experience at OpenAPI Hub - one location for using our validation tools and finding your workflow.

Changelog

Add a changelog entry for this PR by answering the following questions:

1. What's the purpose of the update?
   • new service onboarding
   • new API version
   • update existing version for new feature
   • update existing version to fix swagger quality issue in s360
   • Other, please clarify
2. When are you targeting to deploy the new service/feature to public regions? Please provide the date or, if the date is not yet available, the month.

The new APIs that are added are internal APIs and the target for Private preview is Jan/Feb 2022. Please do not merge these APIs as they have not been implemented yet.
Note: The new changes are done on top of a new version release for CDN (2021-06-01) which is not yet merged into main.

3. When do you expect to publish the swagger? Please provide date or, the the date is not yet available, the month.

January/February

4. If updating an existing version, please select the specific langauge SDKs and CLIs that must be refreshed after the swagger is published.
   • SDK of .NET (need service team to ensure code readiness)
   • SDK of Python
   • SDK of Java
   • SDK of Js
   • SDK of Go
   • PowerShell
   • CLI
   • Terraform
   • No refresh required for updates in this PR

Contribution checklist:

• I commit to follow the Breaking Change Policy of "no breaking changes"
• I have reviewed the documentation for the workflow.
• Validation tools were run on swagger spec(s) and errors have all been fixed in this PR. How to fix?

If any further question about AME onboarding or validation tools, please view the FAQ.

ARM API Review Checklist

Applicability: ⚠️

If your changes encompass only the following scenarios, you should SKIP this section, as these scenarios do not require ARM review.

• Change to data plane APIs
• Adding new properties
• All removals

Otherwise your PR may be subject to ARM review requirements. Complete the following:

• Check this box if any of the following apply to the PR so that label "WaitForARMFeedback" will be added automatically to begin ARM API Review. Failure to comply may result in delays to the manifest.

  • Adding a new service
  • Adding new API(s)
  • Adding a new API version
    -[x] To review changes efficiently, ensure you copy the existing version into the new directory structure for first commit and then push new changes, including version updates, in separate commits.

• Ensure you've reviewed following guidelines including ARM resource provider contract and REST guidelines. Estimated time (4 hours). This is required before you can request review from ARM API Review board.

• If you are blocked on ARM review and want to get the PR merged with urgency, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.

Breaking Change Review Checklist

If any of the following scenarios apply to the PR, request approval from the Breaking Change Review Board as defined in the Breaking Change Policy.

• Removing API(s) in a stable version
• Removing properties in a stable version
• Removing API version(s) in a stable version
• Updating API in a stable or public preview version with Breaking Change Validation errors
• Updating API(s) in public preview over 1 year (refer to Retirement of Previews)

Action: to initiate an evaluation of the breaking change, create a new intake using the template for breaking changes. Addition details on the process and office hours are on the Breaking change Wiki.

Please follow the link to find more details on PR review process.

[mentat9]

resourceState

@mentat9 : Thanks for the clarification. The API that we are creating will be used by another internal team to apply policy through ARM. So the customer for our API is the internal team. The new resource that we created is called 'Policy'. this resource will not be created through the Azure portal. As you suggested, we can remove POST action and use PUT to basically apply the policy. But to go with this change, I have a couple of clarifications. If we go with PUT instead of POST, then Policy resource would have both 'ServiceType' and 'CustomerConfig' as their property, so that when the customer does a PUT on policy we use the customerConfig json blob to apply that policy. Is this a correct appraoch and to go with this change, what's the limitation on the payload size for the PUT action and what are the additional validations we need to take care?

@priyadmurugan, ARM payload size limit is 8Mb. Stepping back for a minute, you are adding CRUD APIs for a policy type. These APIs create, retrieve, update and delete an ARM resource type named "policy". Couple of questions about your design:

1. If I create a policy, but do nothing else, will it be enforced anywhere, or is it just a rule that's available for me to use in the future?
2. Can a single policy be applied to multiple different resources/contexts/scenarios?
3. What exactly does the POST action "applyPolicy" do?

[ghost]

Hi, @priyadmurugan. Your PR has no update for 14 days and it is marked as stale PR. If no further update for over 14 days, the bot will close the PR. If you want to refresh the PR, please remove no-recent-activity label.

[priyadmurugan]

resourceState

@mentat9 : Thanks for the clarification. The API that we are creating will be used by another internal team to apply policy through ARM. So the customer for our API is the internal team. The new resource that we created is called 'Policy'. this resource will not be created through the Azure portal. As you suggested, we can remove POST action and use PUT to basically apply the policy. But to go with this change, I have a couple of clarifications. If we go with PUT instead of POST, then Policy resource would have both 'ServiceType' and 'CustomerConfig' as their property, so that when the customer does a PUT on policy we use the customerConfig json blob to apply that policy. Is this a correct appraoch and to go with this change, what's the limitation on the payload size for the PUT action and what are the additional validations we need to take care?

@priyadmurugan, ARM payload size limit is 8Mb. Stepping back for a minute, you are adding CRUD APIs for a policy type. These APIs create, retrieve, update and delete an ARM resource type named "policy". Couple of questions about your design:

1. If I create a policy, but do nothing else, will it be enforced anywhere, or is it just a rule that's available for me to use in the future?
2. Can a single policy be applied to multiple different resources/contexts/scenarios?
3. What exactly does the POST action "applyPolicy" do?

@mentat9: Earlier we were planning to do CRUD on policy resource and use applypolicy POST action on policy resource to apply the policy (json blob) on profile resource. I was trying to understand if we can use PUT on policy itself to perform functionality which applypolicy POST action would have done. Is that possible? Also, the reason we went with POST action applyPolicy is to overcome the ARM payload size limitation. As per my understand there is no limit on the payload size for POST action. Is that right? I have answered your questions below:

1. If I create a policy, but do nothing else, will it be enforced anywhere, or is it just a rule that's available for me to use in the future?
   This policy would be a resource that will be created with PUT action and then used to call applyPolicy POST action to apply policies to the profile.

2. Can a single policy be applied to multiple different resources/contexts/scenarios?
   We have 1-1 mapping between policy and profile (parent resource)

3. What exactly does the POST action "applyPolicy" do?

It applies the json blob which is the policy on the profile resource.

[priyadmurugan]

resourceState

@mentat9 : Thanks for the clarification. The API that we are creating will be used by another internal team to apply policy through ARM. So the customer for our API is the internal team. The new resource that we created is called 'Policy'. this resource will not be created through the Azure portal. As you suggested, we can remove POST action and use PUT to basically apply the policy. But to go with this change, I have a couple of clarifications. If we go with PUT instead of POST, then Policy resource would have both 'ServiceType' and 'CustomerConfig' as their property, so that when the customer does a PUT on policy we use the customerConfig json blob to apply that policy. Is this a correct appraoch and to go with this change, what's the limitation on the payload size for the PUT action and what are the additional validations we need to take care?

@priyadmurugan, ARM payload size limit is 8Mb. Stepping back for a minute, you are adding CRUD APIs for a policy type. These APIs create, retrieve, update and delete an ARM resource type named "policy". Couple of questions about your design:

1. If I create a policy, but do nothing else, will it be enforced anywhere, or is it just a rule that's available for me to use in the future?
2. Can a single policy be applied to multiple different resources/contexts/scenarios?
3. What exactly does the POST action "applyPolicy" do?

@mentat9: Earlier we were planning to do CRUD on policy resource and use applypolicy POST action on policy resource to apply the policy (json blob) on profile resource. I was trying to understand if we can use PUT on policy itself to perform functionality which applypolicy POST action would have done. Is that possible? Also, the reason we went with POST action applyPolicy is to overcome the ARM payload size limitation. As per my understand there is no limit on the payload size for POST action. Is that right? I have answered your questions below:

1. If I create a policy, but do nothing else, will it be enforced anywhere, or is it just a rule that's available for me to use in the future?
   This policy would be a resource that will be created with PUT action and then used to call applyPolicy POST action to apply policies to the profile.

2. Can a single policy be applied to multiple different resources/contexts/scenarios?
   We have 1-1 mapping between policy and profile (parent resource)

3. What exactly does the POST action "applyPolicy" do?

It applies the json blob which is the policy on the profile resource.

@mentat9 : I have removed post action and will be implementing it as you suggested with put approach.

[mentat9]

  "put": {

This method still needs the x-ms-long-running-operation extension if it's using the async pattern.

---

Refers to: specification/cdn/resource-manager/Microsoft.Cdn/preview/2022-01-01-preview/cdn.json:2255 in b410f4c. [](commit_id = b410f4c, deletion_comment = False)

[mentat9]

@priyadmurugan, I reviewed the latest iterations and it looks good, modulo one comment. Also, for future reference, you can get a faster turnaround from ARM review on PR updates that cross into the next week if you tag or directly ping the current oncall when you are ready for re-review (the labels are also good, but sometimes get overlooked across the next week handoff/transition).

[priyadmurugan]

@priyadmurugan, I reviewed the latest iterations and it looks good, modulo one comment. Also, for future reference, you can get a faster turnaround from ARM review on PR updates that cross into the next week if you tag or directly ping the current oncall when you are ready for re-review (the labels are also good, but sometimes get overlooked across the next week handoff/transition).

@mentat9 : I have addressed your PR review comments. My new version is based of 2021-06 version which was merged after I created PR and I see that there are few changes there that are missing in my new version. Would you suggest me to update them manually or probably create a new PR by having first commit with that version, followed by my changes?

[mentat9]

@priyadmurugan, I reviewed the latest iterations and it looks good, modulo one comment. Also, for future reference, you can get a faster turnaround from ARM review on PR updates that cross into the next week if you tag or directly ping the current oncall when you are ready for re-review (the labels are also good, but sometimes get overlooked across the next week handoff/transition).

@mentat9 : I have addressed your PR review comments. My new version is based of 2021-06 version which was merged after I created PR and I see that there are few changes there that are missing in my new version. Would you suggest me to update them manually or probably create a new PR by having first commit with that version, followed by my changes?

Go ahead and make the new PR exactly as you described. Include a link back to this PR in your comments when/after you submit the new PR.

[priyadmurugan]

Closing this PR, as there is another PR open for the same changes; #17539