-
Notifications
You must be signed in to change notification settings - Fork 5.4k
SRP Jan25 [2025-01-01] API Version Swagger Changes #33529
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?
Conversation
API Change CheckAPIView identified API level changes in this PR and created the following API reviews
|
specification/storage/resource-manager/Microsoft.Storage/stable/2025-01-01/storage.json
Outdated
Show resolved
Hide resolved
specification/storage/resource-manager/Microsoft.Storage/stable/2025-01-01/storage.json
Outdated
Show resolved
Hide resolved
specification/storage/resource-manager/Microsoft.Storage/stable/2025-01-01/blob.json
Show resolved
Hide resolved
specification/storage/resource-manager/Microsoft.Storage/stable/2025-01-01/table.json
Show resolved
Hide resolved
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.
Besides my other comments, please don't merge the PR before this API version is really available in all regions (include mooncake, usgov, ....)
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. |
A SRP swagger PR is merged with 2024-01-01 API change. |
|
PR validation pipeline can not start as the pull request is not merged or mergeable - most likely it has merge conflicts. |
**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
done |
SRP swagger changes for Zonal placement, encryption and restore account
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 |
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.