Release Metadata 2023-02-01 stable version. #22161
Conversation
|
Hi, @samuelkuangms Thanks for your PR. I am workflow bot for review process. Here are some small tips. Any feedback about review process or workflow bot, pls contact swagger and tools team. [email protected] |
Swagger Generation Artifacts
|
Generated ApiView
|
openapi-workflow-bot
bot
added
ARMReview
WaitForARMFeedback
|
Hi, @samuelkuangms your PR are labelled with WaitForARMFeedback. A notification email will be sent out shortly afterwards to notify ARM review board([email protected]). |
|
PR is not generated properly for a new API version The first commit needs to be the previous api version and the new changes should only be added in the subsequent commits. This is explained in detail here (If using Open API which is recommended) https://dev.azure.com/azure-sdk/internal/_wiki/wikis/internal.wiki/208/OpenAPI-Hub-Adding-new-API-version or here(For manual process) : https://dev.azure.com/azure-sdk/internal/_wiki/wikis/internal.wiki/83/Manual-Process-Adding-new-API-version . Please remove the "ARMChangesRequested" label once you have fixed this issue. In reply to: 1396209086 |
raosuhas
added
the
ARMChangesRequested
|
Please ensure to respond feedbacks from the ARM API reviewer. When you are ready to continue the ARM API review, please remove |
openapi-workflow-bot
bot
removed
the
WaitForARMFeedback
@raosuhas should I create a new PR that copy the latest Metadata service 2022-12-01-preview version as the first commit? In reply to: 1397610444 |
samuelkuangms
removed
the
ARMChangesRequested
openapi-workflow-bot
bot
added
the
WaitForARMFeedback
|
@raosuhas please review the last commit, which contains all changes to fix validation error and version change. based on the version 2022-12-01-preview. In reply to: 1397738618 |
| "type": "string" | ||
| }, | ||
| "metadataKind": { | ||
| "type": "string", |
There was a problem hiding this comment.
This is not really recommended :
https://eng.ms/docs/products/arm/rp_onboarding/process/api_review_best_practices
String types that should have enums
If a property has a finite set of values (enforced by the service), the string property should be declared as an enum type in the Swagger (using the x-ms-enum annotation) to enable client-side input validation and discovery.
Can you please explain why you are switching from enum to string ? #Resolved
There was a problem hiding this comment.
@dw511214992 would this change be considered breaking ? changing a type from enum to string ?
There was a problem hiding this comment.
Hi, @raosuhas:
We don't enforce a finite set of values for the property anymore, although it was enforced in older version.
the reason is that CAT team can release new kind or sub kind of content at any time, our service shouldn't limit its capability in this regard.
In backend service, we'll maintain backward compatibility until the pP, PP versions deprecated. but in the meantime the Pr doesn't introduce any breaking change.
There was a problem hiding this comment.
@JeffreyRichter , can you please suggest if changing from enum to string be a breaking change?
There was a problem hiding this comment.
Yes, it is breaking because the SDKs will generate different code and customers who use an SDK will be forced to modify their code.
There was a problem hiding this comment.
But you already shipped some SDKs in the past right? Azures policy is that a customers must be able to adopt a new SDK or service version without requiring the customer make any code changes. If the enum changes to string, then ALL existing SDK customers will have to change their code to adopt the new version.
THis will actually hinder adopting of your new service version & SDK.
There was a problem hiding this comment.
@JeffreyRichter, I am sure that NO SDK has been shipped in the past and NO customer has started to access the service via SDK. we scrutinized our situation prior to proposing the changes.
There was a problem hiding this comment.
OK, then we can allow the "break" since it won't break anyone.
There was a problem hiding this comment.
Thank you @JeffreyRichter!
There was a problem hiding this comment.
Breaking changes are approved.
raosuhas
added
the
ARMChangesRequested
openapi-workflow-bot
bot
removed
the
WaitForARMFeedback
samuelkuangms
removed
the
ARMChangesRequested
openapi-workflow-bot
bot
added
the
WaitForARMFeedback
visingla-ms
added
the
ARMSignedOff
openapi-workflow-bot
bot
removed
the
WaitForARMFeedback
* Adds base for updating Microsoft.SecurityInsights from version stable/2022-11-01 to version 2023-02-01 * Updates readme * Updates API version in new specs and examples * Provider sync properties (#22198) * Alert Rules - add alert details override changes and PUT example (#22196) * add alert details override changes and PUT example * add missing brace * add closing brace for alertDetailsOverride * add dynamic properties to 200 response * add dynamic details to 201 response --------- Co-authored-by: ShaniFelig <[email protected]> * Release Metadata 2023-02-01 stable version. (#22161) * Release Metadata 2023-02-01 stable version. * Fix Swagger spec validation errors. * Revert Metadata service version to 2022-12-01-preview * Bring back changes for version 2023-02-01 * Fix model validation --------- Co-authored-by: Dor Siso <[email protected]> Co-authored-by: ShaniFelig <[email protected]> Co-authored-by: ShaniFelig <[email protected]> Co-authored-by: Samuel Kuang <[email protected]>
* Adds base for updating Microsoft.SecurityInsights from version stable/2022-11-01 to version 2023-02-01 * Updates readme * Updates API version in new specs and examples * Provider sync properties (Azure#22198) * Alert Rules - add alert details override changes and PUT example (Azure#22196) * add alert details override changes and PUT example * add missing brace * add closing brace for alertDetailsOverride * add dynamic properties to 200 response * add dynamic details to 201 response --------- Co-authored-by: ShaniFelig <[email protected]> * Release Metadata 2023-02-01 stable version. (Azure#22161) * Release Metadata 2023-02-01 stable version. * Fix Swagger spec validation errors. * Revert Metadata service version to 2022-12-01-preview * Bring back changes for version 2023-02-01 * Fix model validation --------- Co-authored-by: Dor Siso <[email protected]> Co-authored-by: ShaniFelig <[email protected]> Co-authored-by: ShaniFelig <[email protected]> Co-authored-by: Samuel Kuang <[email protected]>
ARM API Information (Control Plane)
MSFT employees can try out our new experience at OpenAPI Hub - one location for using our validation tools and finding your workflow.
Azure 1st Party Service can try out the Shift Left experience to initiate API design review from ADO code repo. If you are interested, may request engineering support by filling in with the form https://aka.ms/ShiftLeftSupportForm.
Changelog
Add a changelog entry for this PR by answering the following questions:
Contribution checklist (MS Employees Only):
If any further question about AME onboarding or validation tools, please view the FAQ.
ARM API Review Checklist
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 the label "ARMReview" and "WaitForARMFeedback" will be added by bot to kick off ARM API Review. Missing to check this box in the following scenario may result in delays to the ARM manifest review and deployment.
-[ ] 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. You can use OpenAPIHub to initialize the PR for adding a new version. For more details refer to the wiki.
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 you have any breaking changes as defined in the Breaking Change Policy, request approval from the Breaking Change Review Board.
Action: to initiate an evaluation of the breaking change, create a new intake using the template for breaking changes. Additional details on the process and office hours are on the Breaking Change Wiki.
NOTE: To update API(s) in public preview for over 1 year (refer to Retirement of Previews)
Please follow the link to find more details on PR review process.