Added 2025-03-01-preview swagger for Nginx.NginxPlus #34442
Conversation
Next Steps to MergeNext steps that must be taken to merge this PR:
|
|
PR validation pipeline restarted successfully. If there is ApiView generated, it will be updated in this comment. |
github-actions
bot
added
the
brownfield
API Change CheckAPIView identified API level changes in this PR and created the following API reviews
|
AzureRestAPISpecReview
added
ARMReview
BreakingChangeReviewRequired
|
/azp run |
|
You have several pipelines (over 10) configured to build pull requests in this repository. Specify which pipelines you would like to run by using /azp run [pipelines] command. You can specify multiple pipelines using a comma separated list. |
briantkim93
force-pushed
the
brian/publish_2025_03_01_preview
branch
from
60464f2 to
d724496
Compare
openapi-pipeline-app
bot
added
PipelineBotTrigger
and removed
PipelineBotTrigger
labels
AzureRestAPISpecReview
added
the
ReadyForApiTest
openapi-pipeline-app
bot
added
PipelineBotTrigger
and removed
PipelineBotTrigger
labels
briantkim93
removed
the
ARMChangesRequested
openapi-pipeline-app
bot
added
the
WaitForARMFeedback
I have started new commits off the previous version as of this commit - c596bf6 Does that work ? |
| - code: GetCollectionResponseSchema | ||
| from: swagger.json | ||
| where: $.paths["/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Nginx.NginxPlus/nginxDeployments/{deploymentName}/wafPolicies"] | ||
| reason: This is by design to avoid high bandwidth consumption |
There was a problem hiding this comment.
I don't understand this. How is it going to avoid high bandwidth consumption?
There was a problem hiding this comment.
General saving bandwidth is not a good idea not to follow RPC rules, further discussion may be needed.
| "type": "integer", | ||
| "format": "int32" | ||
| }, | ||
| "Operation-Location": { |
There was a problem hiding this comment.
why Operation-Location? Most Azure APIs use the Azure-AsyncOperation header for this I think.
https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/async-operations
| "max" | ||
| ], | ||
| "description": "The capacity parameters of the profile.", | ||
| "x-ms-client-flatten": true, |
| ], | ||
| "description": "The geo-location where the resource lives" | ||
| }, | ||
| "systemData": { |
| "properties": { | ||
| "$ref": "#/definitions/NginxDeploymentApiKeyRequestProperties" | ||
| }, | ||
| "systemData": { |
| "properties": { | ||
| "$ref": "#/definitions/NginxDeploymentWafPolicyProperties" | ||
| }, | ||
| "systemData": { |
There was a problem hiding this comment.
suggest instead inheriting proxy resource as best practice
| "properties": { | ||
| "$ref": "#/definitions/NginxDeploymentWafPolicyMetadataProperties" | ||
| }, | ||
| "systemData": { |
| "type": { | ||
| "type": "string", | ||
| "readOnly": true | ||
| }, |
There was a problem hiding this comment.
these are implied if you inherit proxyresource
| "time": { | ||
| "type": "string", | ||
| "readOnly": true, | ||
| "description": "The date and time the policy was compiled in UTC." |
| "readOnly": true, | ||
| "description": "A readable string of the current status, and sometimes have the reason for the current state. If the CompilingStatus is Failed the Display Status will be The waf Policy failed to compile." | ||
| }, | ||
| "time": { |
| "readOnly": true | ||
| }, | ||
| "provisioningState": { | ||
| "$ref": "#/definitions/ProvisioningState" |
| "items": { | ||
| "$ref": "#/definitions/NginxDeploymentDefaultWafPolicyProperties" | ||
| }, | ||
| "x-ms-identifiers": [] |
There was a problem hiding this comment.
wouldn't they usually have an identifying property? such as the 'id'?
| } | ||
| } | ||
| }, | ||
| "NginxDeploymentDefaultWafPolicyProperties": { |
| ], | ||
| "x-ms-enum": { | ||
| "modelAsString": true, | ||
| "name": "NginxDeploymentWafPolicyCompilingStatusCode", |
There was a problem hiding this comment.
Just a thought in case it helps:
Would the users of your API want their deployment, triggered by PUT, or PATCH, to only be considered complete once compilation has successfully finished? If so you should probably find a way to reflect this in provisioning state also, e.g. provisioning state should only be succeeded after successful compilation.
idea; YMMV
Worked for me, thanks |
TimLovellSmith
added
the
ARMChangesRequested
openapi-pipeline-app
bot
removed
the
WaitForARMFeedback
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.
Purpose of this PR
What's the purpose of this PR? Check the specific option that applies. This is mandatory!
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:
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 ApiViewcomment 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
suppressions guide to get approval.
Getting help
Purpose of this PRandDue diligence checklist.write accessper aka.ms/azsdk/access#request-access-to-rest-api-or-sdk-repositoriesNext 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.and https://aka.ms/ci-fix.
queuedstate, please add a comment with contents/azp run.This should result in a new comment denoting a
PR validation pipelinehas started and the checks should be updated after few minutes.