-
Notifications
You must be signed in to change notification settings - Fork 5.3k
AppServicePlans.json 2022-09-01- Duplicate model name in spec #23709
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
AppServicePlans.json 2022-09-01- Duplicate model name in spec #23709
Conversation
Hi, @jackofallops 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 pipeline restarted successfully, please wait for status update in this comment. |
Swagger pipeline restarted successfully, please wait for status update in this comment. |
Swagger pipeline restarted successfully. If there is ApiView generated, it will be updated in this comment. |
Thank you for your contribution jackofallops! We will review the pull request and get back to you soon. |
Hi @jackofallops, one or multiple breaking change(s) is detected in your PR. Please check out the breaking change(s), and provide business justification in the PR comment and @ PR assignee why you must have these change(s), and how external customer impact can be mitigated. Please ensure to follow breaking change policy to request breaking change review and approval before proceeding swagger PR review. |
Hi @jackofallops, Your PR has some issues. Please fix the CI sequentially by following the order of
|
@microsoft-github-policy-service agree company="Hashicorp" |
@jackofallops Please fill in the correct checkboxes in the first comment so we can get a quick overview of what's going on with this PR and make sure you've understood the relevant linked docs. |
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
@jackofallops Could you please follow this suggestion ? |
Hi @navba-MSFT - The referenced comment was made at 5am my time (UK), so I've only just seen it. I'm not a Microsoft employee, so do not have access to the links in the first comment, and the section is for MSFT employees only? Can you be more specific about the additional information needed? The issue describes the problem, and this PR is a self-explanatory change to address a violation in the spec, but I'm happy to provide additional info as required or make amendments to the PR as needed? Thanks! |
@jackofallops Please update the PR description here. |
Hi @navba-MSFT - I'd be happy to. Can you please be specific about what is necessary to be updated? I have completed all I that I am instructed to in the template, and having checked many other open PRs none have any further information than I have provided. Please elaborate. @jackofallops I have updated the PR description |
@JeffreyRichter Could you help take a look at the breaking change of this PR ? Thanks |
Ideally, the models for PUT and PATCH are identical. This way, a customer could create and initialize a struct via an SDK and then pass that to either a PUT or PATCH method. Or call a GET (which returns an initialized struct) and then pass that to PUT or PATCH. It seems to me that you are purposely making the models different. That being said, if the service has already GA'd then we don't want to introduce a breaking change. So is this change correcting the swagger to make it accurately reflect the currently-shipping service behavior? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Comment added. The "name" of body parameter seems cosmetic.
Also, should you target the next api-version release branch? e.g. as #23567
@@ -279,7 +279,7 @@ | |||
"type": "string" | |||
}, | |||
{ | |||
"name": "appServicePlan", | |||
"name": "appServicePlanPatch", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the change of "name" on body parameter seems unnecessary, as probably only python uses the "name" (it won't affect REST API -- body is body, but it may break SDK if they indeed uses the "name" of body).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jackofallops FYI
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This makes the SDK generation non-deterministic? If this is used as is, the wrong model will be selected (without some override) in some languages SDKs (Python/Go etc). So the PATCH will use the PUT model here, so this is correcting this. This should have a unique name in this spec as it refers to a different model to the PUT, as @JeffreyRichter called out above:
That being said, if the service has already GA'd then we don't want to introduce a breaking change. So is this change correcting the swagger to make it accurately reflect the currently-shipping service behavior?
Ideally, we'd not want this to refer to another model, as this doesn't match standard behaviour in this and other APIs, but if there's legitimate reason not to, we should update here for the name to be unique?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a parameter name, not a model name.
The model is here (which is the correct one AppServicePlanPatchResource
?)
Lines 286 to 288 in f0e0f76
"schema": { | |
"$ref": "#/definitions/AppServicePlanPatchResource" | |
} |
This model will be used whatever the parameter name.
I know Java don't need this change (though it won't break as well; probably same for .NET). API signature would be patch(String, String, ..., AppServicePlanPatchResource)
, parameter name would not show anywhere.
Add @msyyc for Python, @tadelesh for Go.
@jackofallops If this change is intended for SDK, do talk to SDK owners. I've already added them above.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jackofallops Could you please let us know the intended SDK ? Depending on that we can tag the right SDK owners.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@navba-MSFT this change is for github.com/hashicorp/go-azure-sdk (so we'd be the owners/folks to tag there, fwiw)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It will not break Azure Go SDK. But it is labeled as a swagger breaking change (though I don't think it will break payload), it's better to get approval from Jeff.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here's what I think is happening: Today, there is an SDK-only method parameter named appServicePlan and there is desire to change this name to appServicePlanPatch. I'm not sure why this desire exists but the only real language it might affect is C#; not Go. And this has such a small chance of breaking .NET that we'd approve it. But I don't understand the motivation for making this change?
Do I have this right?
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
Next Steps to MergeNext steps that must be taken to merge this PR:
|
The models for Create (PUT) and Update (PATCH) of Service Plans are different, but named the same making the parsing of the spec non-deterministic. These should have unique names within the spec.
azure-rest-api-specs/specification/web/resource-manager/Microsoft.Web/stable/2022-09-01/AppServicePlans.json
Lines 175 to 183 in b0fe180
azure-rest-api-specs/specification/web/resource-manager/Microsoft.Web/stable/2022-09-01/AppServicePlans.json
Lines 281 to 289 in b0fe180
fixes #23708
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.
fixes #23708