Adding tags under properties in both springbootservers and springbootapps
ARM (Control Plane) API Specification Update Pull Request
Tip: overwhelmed by all this guidance? See the
Getting helpsection at the bottom of this PR description.
PR review workflow diagram
Please understand this diagram before proceeding. It explains how to get your PR approved & merged.
Click here to see the details of Step 1
Breaking changes review (Diagram Step 1)
If the automation determines you have breaking changes, i.e. Step 1 from the diagram applies to you,
you must follow the breaking changes process.
IMPORTANT This applies even if:
- The tool fails while it shouldn't, e.g. due to runtime exception, or incorrect detection of breaking changes.
- You believe there is no need for you to request breaking change approval, for any reason. Such claims must be reviewed, and the process is the same.
Click here to see the details of Step 2
ARM API changes review (Diagram Step 2)
- If this PR is in purview of ARM review then automation will add the
ARMReviewlabel. - If you want to force ARM review, add the label yourself.
- Proceed according to the diagram at the top of this comment.
Click here to see the diagram footnotes
Diagram footnotes
[1] ARM review queue (for merge queues, see [2])
The PRs are processed by time opened, ascending. Your PR may show up on 2nd or later page.
If you addressed Step 1 from the diagram and your PR is not showing up in the queue, ensure the label ARMChangesRequested
is removed from your PR. This should cause the label WaitForARMFeedback to be added.
[2] public repo merge queue, private repo merge queue (for ARM review queue, [1])
If you need further help with anything, see Getting help section below.
Purpose of this PR
What's the purpose of this PR? Check all that apply. This is mandatory!
- [ ] New API version. (If API spec is not defined in TypeSpec, the PR should have been generated using OpenAPI Hub).
- [ ] Update existing version for a new feature. (This is applicable only when you are revising a private preview API version.)
- [ ] Update existing version to fix swagger quality issues in S360.
- [ ] Other, please clarify:
- edit this with your clarification
Due diligence checklist
To merge this PR, you must go through the following checklist and confirm you understood and followed the instructions by checking all the boxes:
- [ ] I confirm this PR is modifying Azure Resource Manager (ARM) related specifications, and not data plane related specifications.
- [ ] I have reviewed following Resource Provider guidelines, including
ARM resource provider contract and
REST guidelines (estimated time: 4 hours).
I understand this is required before I can proceed to the Diagram Step 2, "ARM API changes Review", for this PR.
Additional information
Viewing API changes
For convenient view of the API changes made by this PR, refer to the URLs provided in the table
in the Generated ApiView comment added to this PR. You can use ApiView to show API versions diff.
Suppressing failures
If one or multiple validation error/warning suppression(s) is detected in your PR, please follow the Swagger-Suppression-Process to get approval.
Getting help
- First, please carefully read through this PR description, from top to bottom. Please fill out the
Purpose of this PRandDue diligence checklist. - To understand what you must do next to merge this PR, see the
Next Steps to Mergecomment. It will appear within few minutes of submitting this PR and will continue to be up-to-date with current PR state. - For guidance on fixing this PR CI check failures, see the hyperlinks provided in given failure and https://aka.ms/ci-fix.
- If the PR CI checks appear to be stuck in
queuedstate, please add a comment with contents/azp run. This should result in a new comment denoting aPR validation pipelinehas started and the checks should be updated after few minutes. - If the help provided by the previous points is not enough, post to https://aka.ms/azsdk/support/specreview-channel and link to this PR.
Next Steps to Merge
Next steps that must be taken to merge this PR:- ❌ Your PR is in purview of ARM review (label:
ARMReview). Please ensure your PR is on the ARM PR review queue - see instructions in steps 1 and 2 in the PR description diagram. - ❌ The required check named
Swagger BreakingChangehas failed. Refer to the check in the PR's 'Checks' tab for details on how to fix it. In addition, refer to step 1 in the PR workflow diagram (even if your PR is for data plane, not ARM).
Important checks have failed. As of today they are not blocking this PR, but in near future they will.
Addressing the following failures is highly recommended:
- ⚠️ The check named
TypeSpec Requirementhas failed. TypeSpec usage is required for all new (greenfield) services. This is currently enforced as a warning, but will be made a blocking error in the near future. For information on converting from OpenAPI specs to TypeSpec specs or on data-plane (DP) policies, refer to aka.ms/azsdk/typespec. If you have general questions on resource provider (RP) policies, refer to aka.ms/rphelp.
Swagger Validation Report
️❌BreakingChange: 1 Errors, 0 Warnings failed [Detail]
| Rule | Message |
|---|---|
Runtime Exception |
"new":"https://github.com/Azure/azure-rest-api-specs/blob/7b0c182794fd93db6e3022d9f6d745168c014a90/specification/offazurespringboot/resource-manager/Microsoft.OffAzureSpringBoot/preview/2023-01-01-preview/springbootdiscovery.json", "old":"https://github.com/Azure/azure-rest-api-specs/blob/main/specification/offazurespringboot/resource-manager/Microsoft.OffAzureSpringBoot/preview/2023-01-01-preview/springbootdiscovery.json", "details":"Breaking change detector (OAD) invoked AutoRest. AutoRest threw a runtime error. First 6 lines of stack trace follow, indexed. First line should contain AutoRest command line invocation details. Second line should contain the main message reported by AutoRest. ==================== 1: Command failed: node "/mnt/vss/_work/_tasks/AzureApiValidation_5654d05d-82c1-48da-ad8f-161b817f6d41/0.0.77/common/temp/node_modules/.pnpm/@[email protected]/node_modules/autorest/dist/app.js" --v2 --input-file=/mnt/vss/_work/1/same-version-c93b354fd9c14905bb574a8834c4d69b/specification/offazurespringboot/resource-manager/Microsoft.OffAzureSpringBoot/preview/2023-01-01-preview/springbootdiscovery.json --output-artifact=swagger-document.json --output-artifact=swagger-document.map --output-file=old --output-folder=/tmp -------------------- 2: ERROR: Schema violation: Array is too short (0), minimum 1 -------------------- 3: - file:///mnt/vss/_work/1/same-version-c93b354fd9c14905bb574a8834c4d69b/specification/offazurespringboot/resource-manager/Microsoft.OffAzureSpringBoot/preview/2023-01-01-preview/springbootdiscovery.json:1242:6 ($.definitions.springbootsitesPatch.required) -------------------- 4: FATAL: swagger-document/individual/schema-validator - FAILED -------------------- 5: FATAL: Error: [OperationAbortedException] Error occurred. Exiting. -------------------- 6: Process() cancelled due to exception : [OperationAbortedException] Error occurred. Exiting. --------------------" |
️️✔️Breaking Change(Cross-Version) succeeded [Detail] [Expand]
There are no breaking changes.
️️✔️CredScan succeeded [Detail] [Expand]
There is no credential detected.
️️✔️LintDiff succeeded [Detail] [Expand]
Validation passes for LintDiff.
️️✔️Avocado succeeded [Detail] [Expand]
Validation passes for Avocado.
️️✔️SwaggerAPIView succeeded [Detail] [Expand]
️️✔️TypeSpecAPIView succeeded [Detail] [Expand]
️️✔️ModelValidation succeeded [Detail] [Expand]
Validation passes for ModelValidation.
️️✔️SemanticValidation succeeded [Detail] [Expand]
Validation passes for SemanticValidation.
️️✔️PoliCheck succeeded [Detail] [Expand]
Validation passed for PoliCheck.
️️✔️SpellCheck succeeded [Detail] [Expand]
Validation passes for SpellCheck.
️️✔️Lint(RPaaS) succeeded [Detail] [Expand]
Validation passes for Lint(RPaaS).
️️✔️PR Summary succeeded [Detail] [Expand]
Validation passes for Summary.
️️✔️Automated merging requirements met succeeded [Detail] [Expand]
Swagger Generation Artifacts
️️✔️ApiDocPreview succeeded [Detail] [Expand]
Please click here to preview with your @microsoft account.
️❌SDK Breaking Change Tracking failed [Detail]
Breaking Changes Tracking
❌azure-sdk-for-go - sdk/resourcemanager/springappdiscovery/armspringappdiscovery - 0.2.0+ Field `ID`, `Location`, `Name`, `SystemData`, `Type` of struct `SpringbootsitesPatch` has been removed + Field `SiteName` of struct `SpringbootappsProperties` has been removed + Operation `*SpringbootappsClient.BeginUpdate` has been changed to non-LRO, use `*SpringbootappsClient.Update` instead. + Operation `*SpringbootserversClient.BeginUpdate` has been changed to non-LRO, use `*SpringbootserversClient.Update` instead.
❌azure-sdk-for-python-track2 - track2_azure-mgmt-springappdiscovery - 1.0.0b1+ Model SpringbootappsProperties no longer has parameter site_name + Model SpringbootsitesPatch no longer has parameter id + Model SpringbootsitesPatch no longer has parameter location + Model SpringbootsitesPatch no longer has parameter name + Model SpringbootsitesPatch no longer has parameter system_data + Model SpringbootsitesPatch no longer has parameter type + Removed operation SpringbootappsOperations.begin_update + Removed operation SpringbootserversOperations.begin_update
❌azure-sdk-for-js - @azure/arm-springappdiscovery - 1.0.0-beta.2+ Interface SpringbootappsProperties no longer has parameter siteName + Interface SpringbootappsUpdateOptionalParams no longer has parameter resumeFrom + Interface SpringbootappsUpdateOptionalParams no longer has parameter updateIntervalInMs + Interface SpringbootserversUpdateOptionalParams no longer has parameter resumeFrom + Interface SpringbootserversUpdateOptionalParams no longer has parameter updateIntervalInMs + Removed operation Springbootapps.beginUpdate + Removed operation Springbootapps.beginUpdateAndWait + Removed operation Springbootservers.beginUpdate + Removed operation Springbootservers.beginUpdateAndWait
️️✔️ azure-sdk-for-net-track2 succeeded [Detail] [Expand]
️✔️Succeeded [Logs] Generate from 22f1a21204b434bc4ee408790492ba3a78fe6829. SDK Automation 14.0.0command pwsh ./eng/scripts/Automation-Sdk-Init.ps1 ../azure-sdk-for-net_tmp/initInput.json ../azure-sdk-for-net_tmp/initOutput.json command pwsh ./eng/scripts/Invoke-GenerateAndBuildV2.ps1 ../azure-sdk-for-net_tmp/generateInput.json ../azure-sdk-for-net_tmp/generateOutput.json
️✔️Azure.ResourceManager.Offazurespringboot [View full logs] [Preview SDK Changes]info [Changelog]
️⚠️ azure-sdk-for-python-track2 warning [Detail]
⚠️Warning [Logs] Generate from 22f1a21204b434bc4ee408790492ba3a78fe6829. SDK Automation 14.0.0command sh scripts/automation_init.sh ../azure-sdk-for-python_tmp/initInput.json ../azure-sdk-for-python_tmp/initOutput.json cmderr [automation_init.sh] WARNING: azure-devtools 1.2.1 does not provide the extra 'ci-tools' cmderr [automation_init.sh] WARNING: azure-devtools 1.2.1 does not provide the extra 'ci-tools' cmderr [automation_init.sh] WARNING: Skipping azure-nspkg as it is not installed. command sh scripts/automation_generate.sh ../azure-sdk-for-python_tmp/generateInput.json ../azure-sdk-for-python_tmp/generateOutput.json cmderr [automation_generate.sh] npm notice cmderr [automation_generate.sh] npm notice New minor version of npm available! 10.2.3 -> 10.4.0 cmderr [automation_generate.sh] npm notice Changelog: <https://github.com/npm/cli/releases/tag/v10.4.0> cmderr [automation_generate.sh] npm notice Run `npm install -g [email protected]` to update! cmderr [automation_generate.sh] npm notice
️✔️track2_azure-mgmt-springappdiscovery [View full logs] [Preview SDK Changes]
️️✔️ azure-sdk-for-go succeeded [Detail] [Expand]
️✔️Succeeded [Logs] Generate from 22f1a21204b434bc4ee408790492ba3a78fe6829. SDK Automation 14.0.0command sh ./eng/scripts/automation_init.sh ../../../../../azure-sdk-for-go_tmp/initInput.json ../../../../../azure-sdk-for-go_tmp/initOutput.json command generator automation-v2 ../../../../../azure-sdk-for-go_tmp/generateInput.json ../../../../../azure-sdk-for-go_tmp/generateOutput.json
️✔️sdk/resourcemanager/springappdiscovery/armspringappdiscovery [View full logs] [Preview SDK Changes]
️️✔️ azure-sdk-for-js succeeded [Detail] [Expand]
️✔️Succeeded [Logs] Generate from 22f1a21204b434bc4ee408790492ba3a78fe6829. SDK Automation 14.0.0command sh .scripts/automation_init.sh ../azure-sdk-for-js_tmp/initInput.json ../azure-sdk-for-js_tmp/initOutput.json warn File azure-sdk-for-js_tmp/initOutput.json not found to read command sh .scripts/automation_generate.sh ../azure-sdk-for-js_tmp/generateInput.json ../azure-sdk-for-js_tmp/generateOutput.json
️✔️@azure/arm-springappdiscovery [View full logs] [Preview SDK Changes]
️⚠️ azure-sdk-for-java warning [Detail]
⚠️Warning [Logs] Generate from 22f1a21204b434bc4ee408790492ba3a78fe6829. SDK Automation 14.0.0command ./eng/mgmt/automation/init.sh ../azure-sdk-for-java_tmp/initInput.json ../azure-sdk-for-java_tmp/initOutput.json cmderr [init.sh] [notice] A new release of pip is available: 23.0.1 -> 24.0 cmderr [init.sh] [notice] To update, run: pip install --upgrade pip cmderr [init.sh] [notice] A new release of pip is available: 23.0.1 -> 24.0 cmderr [init.sh] [notice] To update, run: pip install --upgrade pip cmderr [init.sh] verage Speed Time Time Time Current cmderr [init.sh] Dload Upload Total Spent Left Speed cmderr [init.sh] 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 0 0 1195k 0 --:--:-- --:--:-- --:--:-- 1195k cmderr [init.sh] notice cmderr [init.sh] npm notice New minor version of npm available! 10.2.3 -> 10.4.0 cmderr [init.sh] npm notice Changelog: <https://github.com/npm/cli/releases/tag/v10.4.0> cmderr [init.sh] npm notice Run `npm install -g [email protected]` to update! cmderr [init.sh] npm notice cmderr [init.sh] Downloading https://nodejs.org/dist/v18.15.0/node-v18.15.0-linux-x64.tar.xz... cmderr [init.sh] Computing checksum with sha256sum cmderr [init.sh] Checksums matched! command ./eng/mgmt/automation/generate.py ../azure-sdk-for-java_tmp/generateInput.json ../azure-sdk-for-java_tmp/generateOutput.json
️✔️azure-resourcemanager-springappdiscovery [View full logs] [Preview SDK Changes]
Generated ApiView
| Language | Package Name | ApiView Link |
|---|---|---|
| Go | sdk/resourcemanager/springappdiscovery/armspringappdiscovery | https://apiview.dev/Assemblies/Review/0a5b6199e7eb47c7afd3fccd27aac137?revisionId=e65aad6f21cf4021aaedd01a578766dc |
| .Net | Azure.ResourceManager.Offazurespringboot | https://apiview.dev/Assemblies/Review/06ff03b12da14ababa93d39f68a24a1f?revisionId=92d8ef005f3a4ae2a56110b7563f3ad2 |
| Java | azure-resourcemanager-springappdiscovery | https://apiview.dev/Assemblies/Review/4f6ef8ea4cb24b2ebd2bbe54612934e0?revisionId=3667a7d13c064583932415c4abfbbd08 |
| JavaScript | @azure/arm-springappdiscovery | https://apiview.dev/Assemblies/Review/8cdf0ae6e4284b11861fb5ca0c7d7f98?revisionId=69502c0cb1824c839100b097d636dae9 |
[ARMBlockingComment] @sunkun99 - Please fill out the intake form above.
Please address or respond to feedback from the ARM API reviewer.
When you are ready to continue the ARM API review, please remove the ARMChangesRequested label.
This will notify the reviewer to have another look.
If the feedback provided needs further discussion, please use this Teams channel to post your questions - aka.ms/azsdk/support/specreview-channel.
Please include [ARM Query] in the title of your question to indicate that it is ARM-related.
As of 1/1/24, new ARM spec must be authored in TypeSpec or your PR and SDK may risk unable to merge/release. Please visit this link for more info. We can assist you to migrate to TypeSpec.
As of 1/1/24, new ARM spec must be authored in TypeSpec or your PR and SDK may risk unable to merge/release. Please visit this link for more info. We can assist you to migrate to TypeSpec.
@allenjzhang As it is an existing arm spec, and this pr is updating the old one, if necessary, we can postpond to migrate this to typespec after it's merged
As of 1/1/24, new ARM spec must be authored in TypeSpec or your PR and SDK may risk unable to merge/release. Please visit this link for more info. We can assist you to migrate to TypeSpec.
@allenjzhang As it is an existing arm spec, and this pr is updating the old one, if necessary, we can postpond to migrate this to typespec after it's merged
I understand. It is not blocking as of today but will be soon. Just want to make sure that you are aware of this. Giving API hasn't gone stable, it is critical that we tackle this soon if not asap. Visit this link and engage us for support. https://azure.github.io/typespec-azure/docs/next/howtos/migrate-swagger/get-started
"tags": {
Same here. Since this is on a proxy resource, you need to rename this property to something else and move it into the property bag.
Refers to: specification/offazurespringboot/resource-manager/Microsoft.OffAzureSpringBoot/preview/2023-01-01-preview/springbootdiscovery.json:1435 in 78d7fb5. [](commit_id = 78d7fb5a951500f62bfdb1018eae207cf37df357, deletion_comment = False)
"tags": {
Rename and move into the property bag.
Refers to: specification/offazurespringboot/resource-manager/Microsoft.OffAzureSpringBoot/preview/2023-01-01-preview/springbootdiscovery.json:1457 in 78d7fb5. [](commit_id = 78d7fb5a951500f62bfdb1018eae207cf37df357, deletion_comment = False)
"springbootappsProperties": {
Removing the "siteName" property is a breaking change.
Refers to: specification/offazurespringboot/resource-manager/Microsoft.OffAzureSpringBoot/preview/2023-01-01-preview/springbootdiscovery.json:1488 in 78d7fb5. [](commit_id = 78d7fb5a951500f62bfdb1018eae207cf37df357, deletion_comment = False)
@sunkun99 - Your later changes have introduced breaking changes. I've identified those in PR comments and added the label to route your PR to breaking change review.
"tags": {
There are two separate issues with this property. The property name and its location. Your own tags implementation will absolutely not be allowed at the top-level of a proxy resource. This instance you are adding a tags property at the top level of a proxy resource, so this will block approval whether you rename it or not.
In reply to: 1886036675
Refers to: specification/offazurespringboot/resource-manager/Microsoft.OffAzureSpringBoot/preview/2023-01-01-preview/springbootdiscovery.json:1435 in 78d7fb5. [](commit_id = 78d7fb5a951500f62bfdb1018eae207cf37df357, deletion_comment = False)
"tags": {
Same here: this needs to move to the property bag at minimum.
In reply to: 1886036819
Refers to: specification/offazurespringboot/resource-manager/Microsoft.OffAzureSpringBoot/preview/2023-01-01-preview/springbootdiscovery.json:1457 in 78d7fb5. [](commit_id = 78d7fb5a951500f62bfdb1018eae207cf37df357, deletion_comment = False)
@sunkun99 based on the discussion above , please note the following :
- Having a top level tags properties for a ProxyResource is not supported at all. Please clear up all those instances from your PR. This is a must fix , before we can go ahead with this PR.
For having a "tag-like" property inside the property bag , please note that having the property with the same name as tags is confusing so the recommendation as suggested by @mentat9 is to use some other naming other than tags. PLease fix both these comments before restarting ARM review.
@sunkun99 based on the discussion above , please note the following :
- Having a top level tags properties for a ProxyResource is not supported at all. Please clear up all those instances from your PR. This is a must fix , before we can go ahead with this PR.
For having a "tag-like" property inside the property bag , please note that having the property with the same name as tags is confusing so the recommendation as suggested by @mentat9 is to use some other naming other than tags. PLease fix both these comments before restarting ARM review.
@raosuhas please look at the comments we had discussed before, @mentat9 seemed to agree with this?
@mentat9 now we need to add readonly property in line 1681 to avoid lintdiff violation. We are using arc and rpaas to implements our logic, and arc will call patch method of rpass to sync status of our kubernetes resources on premise to azure. And from arm leg we found rpaas will validate the patch from swagger api. If we add readonly, will it affect patch?
@sunkun99 based on the discussion above , please note the following :
- Having a top level tags properties for a ProxyResource is not supported at all. Please clear up all those instances from your PR. This is a must fix , before we can go ahead with this PR.
For having a "tag-like" property inside the property bag , please note that having the property with the same name as tags is confusing so the recommendation as suggested by @mentat9 is to use some other naming other than tags. PLease fix both these comments before restarting ARM review.
@raosuhas please look at the comments we had discussed before, @mentat9 seemed to agree with this?
Language "agree with this" is too ambiguous. Summarizing feedback from me:
- Including tags in top-level PATCH definition on tracked resource type instead of using $ref to common types TrackedResource definition is OK.
- Including tag-like property within the property bag on proxy resource type is not recommended but is allowed in this case.
- If tag-like property in property bag is defined, it must NOT be named "tags".
- That has been my consistent position and feedback on this PR.
@sunkun99 could you please respond to @mentat9 's clarification above ?
@sunkun99 could you please respond to @mentat9 's clarification above ?
@raosuhas
Let me discuss internally and will response later, thanks.
@raosuhas , @mentat9
As per our product plan, we want to implement properties.tags now before ARM releases TagsV2. We don't want to introduce a tags-like name now and later pivot to v2tags. The user should simply see "tags" now, and in future, when we switch to TagsV2 implementation.
Our thinking is to build the product in such a way that the switch from properties.Tags to TagsV2 should remain fairly transparent in the UI to the users.
Since the RP owns the fields inside the propertybag, can't we use the name "tags" inside it?
In reply to: 1908870213
@raosuhas , @mentat9
As per our product plan, we want to implement properties.tags now before ARM releases TagsV2. We don't want to introduce a tags-like name now and later pivot to v2tags. The user should simply see "tags" now, and in future, when we switch to TagsV2 implementation.
Our thinking is to build the product in such a way that the switch from properties.Tags to TagsV2 should remain fairly transparent in the UI to the users.
Since the RP owns the fields inside the propertybag, can't we use the name "tags" inside it?
In reply to: 1908870213
@sunkun99 - I understand the need for adding a tags-like property in the property bag, but I'm not seeing how naming the property "tags" now will allow clients to transparently access ARM tags V2 in the future. Can you elaborate on that?
These RP tags are not ARM tags and naming them as such is confusing for clients. Tag-like properties won't work with the portal, won't work with Azure Policy, ARG, ARN, or any other service that uses standard ARM tags. Calling it tags is not helping.
Lets call the TagsV2 rolled out time as T2. Lets call the time between now and T2 as T1.
In T1, Properties.Tags will get copied to ARG as that is just like any other property in the proxy resource. Our product UI page displays Properties.Tags as Tags. Product UI can CRUD Properties.Tags using PATCH on the resource.
~90% of our customers use portal UI and for them, these are just Tags We don't have scenarios to use Azure Policy on properties.Tags
In T2, Properties.Tags will be copied to TagsV2(by our RP, if needed) Edit capability on Properties.Tags through PATCH will be removed. Our product UI pages will display TagsV2 as Tags on the resource. Product UI can CRUD TagsV2 using ARM-TagsV2-API.
~90% of our customers don't have to differentiate between tag-like property and tags. For them, its the same. For < ~10% of our customers who use APIs, there is a change in the API. They'll have to use ARM-TagsV2-API instead of PATCH on the resource. The PATCH API on resource will be kept in preview state only until T2.
This is our thinking. Please let us know if something is amiss with this plan of action.
In reply to: 1915457857
Lets call the TagsV2 rolled out time as T2. Lets call the time between now and T2 as T1.
In T1, Properties.Tags will get copied to ARG as that is just like any other property in the proxy resource. Our product UI page displays Properties.Tags as Tags. Product UI can CRUD Properties.Tags using PATCH on the resource.
~90% of our customers use portal UI and for them, these are just Tags We don't have scenarios to use Azure Policy on properties.Tags
In T2, Properties.Tags will be copied to TagsV2(by our RP, if needed) Edit capability on Properties.Tags through PATCH will be removed. Our product UI pages will display TagsV2 as Tags on the resource. Product UI can CRUD TagsV2 using ARM-TagsV2-API.
~90% of our customers don't have to differentiate between tag-like property and tags. For them, its the same. For < ~10% of our customers who use APIs, there is a change in the API. They'll have to use ARM-TagsV2-API instead of PATCH on the resource. The PATCH API on resource will be kept in preview state only until T2.
This is our thinking. Please let us know if something is amiss with this plan of action.
In reply to: 1915457857
@sunkun99 - I understand and acknowledge your approach, but it seems you are looking at your own RP's APIs in isolation as though it's the only Azure functionality your users care about or use. Customers prefer not to think about Azure as a large disjoint collection of different services and APIs. To them, it's all "Azure". To the extent we can provide commonalities across the entire Azure surface area, it helps customers discover, learn, use, and teach others about Azure services.
So when one of your customers applies a "tag" to their resource but can't find them by searching tags (they need to search the property bag unlike any other resource) in ARG or beats their head against the wall when accessing the "tags" field in their policy rule appears to do nothing, it undermines this idea.
Customers have ways of accessing your services besides just the portal blades your team controls. Making these consistent helps users. Even if you have correctly estimated that only 10% of users are doing this, we need to think about them as well.
You plan above sounds otherwise OK (not too sure about automatically copying properties.tags to top-level tags, that would need close examination whenever it gets close enough), but I don't see it undermined by using the term "label" (or something else) instead of "tag". I think trying to hide the fact that a "tag" on a proxy resource is not like a "tag" on a tracked resource is not going to work well.
Lets call the TagsV2 rolled out time as T2. Lets call the time between now and T2 as T1. In T1, Properties.Tags will get copied to ARG as that is just like any other property in the proxy resource. Our product UI page displays Properties.Tags as Tags. Product UI can CRUD Properties.Tags using PATCH on the resource.
~90% of our customers use portal UI and for them, these are just Tags We don't have scenarios to use Azure Policy on properties.Tags
In T2, Properties.Tags will be copied to TagsV2(by our RP, if needed) Edit capability on Properties.Tags through PATCH will be removed. Our product UI pages will display TagsV2 as Tags on the resource. Product UI can CRUD TagsV2 using ARM-TagsV2-API.
~90% of our customers don't have to differentiate between tag-like property and tags. For them, its the same. For < ~10% of our customers who use APIs, there is a change in the API. They'll have to use ARM-TagsV2-API instead of PATCH on the resource. The PATCH API on resource will be kept in preview state only until T2.
This is our thinking. Please let us know if something is amiss with this plan of action. In reply to: 1915457857
@sunkun99 - I understand and acknowledge your approach, but it seems you are looking at your own RP's APIs in isolation as though it's the only Azure functionality your users care about or use. Customers prefer not to think about Azure as a large disjoint collection of different services and APIs. To them, it's all "Azure". To the extent we can provide commonalities across the entire Azure surface area, it helps customers discover, learn, use, and teach others about Azure services.
So when one of your customers applies a "tag" to their resource but can't find them by searching tags (they need to search the property bag unlike any other resource) in ARG or beats their head against the wall when accessing the "tags" field in their policy rule appears to do nothing, it undermines this idea.
Customers have ways of accessing your services besides just the portal blades your team controls. Making these consistent helps users. Even if you have correctly estimated that only 10% of users are doing this, we need to think about them as well.
You plan above sounds otherwise OK (not too sure about automatically copying properties.tags to top-level tags, that would need close examination whenever it gets close enough), but I don't see it undermined by using the term "label" (or something else) instead of "tag". I think trying to hide the fact that a "tag" on a proxy resource is not like a "tag" on a tracked resource is not going to work well.
@mentat9 hello, I had modified the tags under property to labels, and discussed with the service provider, it will work well. Would you please help to review this pr again? Thanks
Please get a breaking changes approval from Azure Breaking Changes Reviewers [email protected] and ARM can review the changes afterwards.
}
This should be removed. As proxy resource should not have tags
Refers to: specification/offazurespringboot/resource-manager/Microsoft.OffAzureSpringBoot/preview/2023-01-01-preview/springbootdiscovery.json:1733 in 7b0c182. [](commit_id = 7b0c182794fd93db6e3022d9f6d745168c014a90, deletion_comment = False)
}
This should be removed
Refers to: specification/offazurespringboot/resource-manager/Microsoft.OffAzureSpringBoot/preview/2023-01-01-preview/springbootdiscovery.json:1755 in 7b0c182. [](commit_id = 7b0c182794fd93db6e3022d9f6d745168c014a90, deletion_comment = False)
},
This should be deleted.
Refers to: specification/offazurespringboot/resource-manager/Microsoft.OffAzureSpringBoot/preview/2023-01-01-preview/springbootdiscovery.json:1439 in 7b0c182. [](commit_id = 7b0c182794fd93db6e3022d9f6d745168c014a90, deletion_comment = False)