SRP Jan25 [2025-01-01] API Version Swagger Changes #33529
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
github-actions
bot
added
the
brownfield
microsoft-github-policy-service
bot
added
the
Storage
API Change CheckAPIView identified API level changes in this PR and created the following API reviews
|
blueww
reviewed
Mar 27, 2025
specification/storage/resource-manager/Microsoft.Storage/stable/2025-01-01/storage.json
Outdated
Show resolved
Hide resolved
blueww
reviewed
Mar 27, 2025
specification/storage/resource-manager/Microsoft.Storage/stable/2025-01-01/storage.json
Outdated
Show resolved
Hide resolved
blueww
reviewed
Mar 27, 2025
specification/storage/resource-manager/Microsoft.Storage/stable/2025-01-01/blob.json
Show resolved
Hide resolved
blueww
reviewed
Mar 27, 2025
specification/storage/resource-manager/Microsoft.Storage/stable/2025-01-01/table.json
Show resolved
Hide resolved
blueww
requested changes
Mar 27, 2025
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. |
This was referenced Mar 27, 2025
|
A SRP swagger PR is merged with 2024-01-01 API change. |
microsoft-github-policy-service
bot
added
the
no-recent-activity
|
microsoft-github-policy-service
bot
removed
the
no-recent-activity
msyyc
reviewed
May 6, 2025
msyyc
reviewed
May 6, 2025
tadelesh
reviewed
May 9, 2025
|
PR validation pipeline can not start as the pull request is not merged or mergeable - most likely it has merge conflicts. |
AzureRestAPISpecReview
added
ARMReview
BreakingChangeReviewRequired
**Code Review Checklist** *Code Style/Hygiene* - [ ] Is the change self-contained ? If not, can this be broken to separate PRs ? - [ ] If this is a new feature, is the entire feature behind a config or allow-listed subscription or AFEC ? Ensure that the feature is turned off by default and enabled only for a select set of subscriptions. - [ ] If a new feature, and AFEC/subscription opt-in is not feasible, can this change be limited to stage/canaries and phased open in a future rollout ? - [ ] Are configs/DCs included for variable limits, settings and to disable the feature off as a whole ? - [ ] If a bug is being fixed that impacts written KVS state, is there a backfill (backfill job) plan in place to repair existing KVS records with bad data ? If not, is the bug fix backward compatible with existing data ? *API versioning* - [ ] Are new customer facing APIs or properties being introduced ? Should this change be introduced in a new API version ? - [ ] Is any existing KVS schema being modified ? If yes, this change should be introduced in a new API version. - [ ] If KVS schema is being modified for persistent state, is there a backfill (backfill job) plan in place to repair existing KVS records with the old schema ? If not, is the change backward compatible with existing KVS data ? *Logging* - [ ] Do any of the log messages include PII or sensitive information eg. keys (account/encryption), customer data (tags) ? - [ ] Are appropriate verbose logs included to diagnose customer issues when this change is deployed ? i.e. are we able to describe a timeline of what happened to a customer request while triggering the new code path ? *Exception/Error Handling* - [ ] Are all non-recoverable errors handled and logged ? Is a user-friendly/actionable error code returned to the user ? - [ ] If non-recoverable error are seen, is the transaction unwound to a clean state to avoid orphaned metadata ? - [ ] If recoverable, are the retries bounded for non-transactional ? - [ ] If recoverable, are the retries unbounded for transactional ? *Memory* - [ ] Are there any unbounded KVS reads eg. list entire KVS tables ? Consider pointed reads by key or paged reads. - [ ] Does the change introduce an increased memory footprint to RSRP replicas ? Do we require memory profiling in preprod/test ? *Performance* - [ ] KVS writes cost 5-15ms. Are there any redundant KVS reads/writes ? - [ ] Do we need to consider secondary indexes to improve operation performance ? *Unit Test Coverage* - [ ] Do unit tests cover all happy path & failure scenarios ? - [ ] Do any of the unit tests introduced rely on randomness or prone to transient failures eg. time skew, randomly selecting account type or request parameter etc ? - [ ] Do the Unit tests take less than 100ms(each) to execute when the test suite is run? - [ ] Do any of the unit tests take a dependency on time, I/O, network call, disks etc? *Monitoring* - [ ] Are metrics created for outbound/inbound external dependenc...
…operty for SMB & NFS in 2025-01-01 **Objective**: To add the swagger for a new file service property - 'EncryptionInTransit' for SMB & NFS, for service version '2026-02-06' . - The example is added in a new file S:\Azure\Storage\Storage-SRP\src\Swagger\Microsoft.Storage\stable\2026-02-06\examples\FileServicesPut_EncryptionInTransitRequired.json **Code Review Checklist** *Code Style/Hygiene* - [ ] Is the change self-contained ? If not, can this be broken to separate PRs ? - [ ] If this is a new feature, is the entire feature behind a config or allow-listed subscription or AFEC ? Ensure that the feature is turned off by default and enabled only for a select set of subscriptions. - [ ] If a new feature, and AFEC/subscription opt-in is not feasible, can this change be limited to stage/canaries and phased open in a future rollout ? - [ ] Are configs/DCs included for variable limits, settings and to disable the feature off as a whole ? - [ ] If a bug is being fixed that impacts written KVS state, is there a backfill (backfill job) plan in place to repair existing KVS records with bad data ? If not, is the bug fix backward compatible with existing data ? *API versioning* - [ ] Are new customer facing APIs or properties being introduced ? Should this change be introduced in a new API version ? - [ ] Is any existing KVS schema being modified ? If yes, this change should be introduced in a new API version. - [ ] If KVS schema is being modified for persistent state, is there a backfill (backfill job) plan in place to repair existing KVS records with the old schema ? If not, is the change backward compatible with existing KVS data ? *Logging* - [ ] Do any of the log messages include PII or sensitive information eg. keys (account/encryption), customer data (tags) ? - [ ] Are appropriate verbose logs included to diagnose customer issues when this change is deployed ? i.e. are we able to describe a timeline of what happened to a customer request while triggering the new code path ? *Exception/Error Handling* - [ ] Are all non-recoverable errors handled and logged ? Is a user-friendly/actionable error code returned to the user ? - [ ] If non-recoverable error are seen, is the transaction unwound to a clean state to avoid orphaned metadata ? - [ ] If recoverable, are the retries bounded for non-transactional ? - [ ] If recoverable, are the retries unbounded for transactional ? *Memory* - [ ] Are there any unbounded KVS reads eg. list entire KVS tables ? Consider pointed reads by key or paged reads. - [ ] Does the change introduce an increased memory footprint to RSRP replicas ? Do we require memory profiling in preprod/test ? *Performance* - [ ] KVS writes cost 5-15ms. Are there any redundant KVS reads/writes ? - [ ] Do we need to consider secondary indexes to improve operation performance ? *Unit Test Coverage* - [ ] Do unit tests cover all happy path & failure scenarios ? - [ ] Do any of the unit tests introduced rely on randomness or prone to transient failures eg. time skew, ...
**Why do we need this change?** We missed the chance to document restore storage account Api, though put storage account operation. This is also causing challenge of build-in policy for related scenario. Task 29330514: Build-in policy Storage_NetworkAcls_Audit.json should consider storage account recovery scenario ---- API change This pull request updates the Swagger documentation to include the restore storage account scenario. - Added `DeletedStorageAccountRestore.json` example for restoring a deleted storage account. - Updated `storage.json` to include `deletedAccountCreationTime` property and reference the new restore example. - Modified the description for the 202 response to include restore storage account requests. <!-- GitOpsUserAgent=GitOps.Apps.Server.pullrequestcopilot --> Related work items: #31884198
AzureRestAPISpecReview
added
the
ReadyForApiTest
done |
ajashant-msft
removed
the
ARMChangesRequested
openapi-pipeline-app
bot
added
the
WaitForARMFeedback
blueww
approved these changes
Jun 5, 2025
SRP swagger changes for Zonal placement, encryption and restore account
AzureRestAPISpecReview
removed
the
ReadyForApiTest
|
There are still a bunch of errors here - https://github.com/Azure/azure-rest-api-specs/pull/33529/checks?check_run_id=43585557082 Please either fix them or provide a justification for wh these cant be fixed |
rkmanda
added
the
ARMChangesRequested
openapi-pipeline-app
bot
removed
the
WaitForARMFeedback
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Choose a PR Template
Switch to "Preview" on this description then select one of the choices below.
Click here to open a PR for a Data Plane API.
Click here to open a PR for a Control Plane (ARM) API.
Click here to open a PR for only SDK configuration.