-
Notifications
You must be signed in to change notification settings - Fork 5.2k
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
[SRP] Add delete retention policy for blob container and file share #7626
Conversation
In Testing, Please Ignore[Logs] (Generated from eb302b3, Iteration 2)
|
Can one of the admins verify this patch? |
Automation for azure-sdk-for-goThe initial PR has been merged into your service PR: |
@@ -1142,6 +1142,10 @@ | |||
"changeFeed": { | |||
"$ref": "#/definitions/ChangeFeed", | |||
"description": "The blob service properties for change feed events." | |||
}, | |||
"containerDeleteRetentionPolicy": { |
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 neww property will be think as breaking change in stable version. suggest to add it in new version
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.
@yungezz
I don't see any reason why add new properties are breaking change, would you please give some reason.
And we have add new properties in same API verison before, but not take as breaking.
Per my understanding, REmove/modify a property will breaking, but add new properties are not breaking.
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.
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.
Yunge, I understand your concern. Adding a new property can cause data lost during update. June19 is the version we added last week. We can't afford to add a new version for every new feature. As Wei mentioned, we have been adding properties in the same API version before, which does not cause any issue.
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.
@yungezz
Thanks for the sharing, from the doc I see : "This will overwrite the change made by the first customer from the portal."
Per my understanding, in current storage object update request, if the request send to server does not contain a property (since not get from server), the property will keep the origin value and won't be updated. @zfchen95 , would you please confirm?
In this case, the GET-PUT pipeline won't be broken, so there are no breaking change.
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.
Correct. If the property is not shown in the request, it will not clear the property.
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.
@yungezz
Do you agree adding the new property in this PR is not a breaking? since it won't break the GET-PUT pipeline. Let us know if you still have concern on this.
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.
@blueww as long as service team can make sure no user breaking experience, we're ok to it.
@@ -432,6 +432,10 @@ | |||
"cors": { | |||
"$ref": "./common.json#/definitions/CorsRules", | |||
"description": "Specifies CORS rules for the File service. You can include up to five CorsRule elements in the request. If no CorsRule elements are included in the request body, all CORS rules will be deleted, and CORS will be disabled for the File service." | |||
}, | |||
"shareDeleteRetentionPolicy": { |
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.
same as 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.
same as above.
@zfchen95 |
The existing delete retention policy is for blob soft delete. The new container delete retention policy is for container soft delete. @priyapansrp may have the documentation. |
These are for two different feature. The first one is for blob soft delete which is different than container soft delete. |
@yungezz Could you remove the DoNotMerge tag. Thanks! |
hi @zfchen95 is the service change public? is the PR ready to merge? |
Automation for azure-sdk-for-pythonEncountered a Subprocess error: (azure-sdk-for-python)
Command: ['/usr/local/bin/autorest', '/tmp/tmp9398nq5i/rest/specification/storage/resource-manager/readme.md', '--perform-load=false', '--swagger-to-sdk', '--output-artifact=configuration.json', '--input-file=foo', '--output-folder=/tmp/tmp95pf5trk'] AutoRest code generation utility [version: 2.0.4283; node: v8.12.0]
(C) 2018 Microsoft Corporation.
https://aka.ms/autorest
Failure:
Error: Unable to start AutoRest Core from /root/.autorest/@microsoft.azure_autorest-core@2.0.4405/node_modules/@microsoft.azure/autorest-core
Error: Unable to start AutoRest Core from /root/.autorest/@microsoft.azure_autorest-core@2.0.4405/node_modules/@microsoft.azure/autorest-core
at main (/opt/node_modules/autorest/dist/app.js:232:19)
at <anonymous>
/root/.autorest/@microsoft.azure_autorest-core@2.0.4405/node_modules/@microsoft.azure/autorest-core/dist/app.js:33
autorest_core_1.Shutdown();
^
ReferenceError: autorest_core_1 is not defined
at process.on (/root/.autorest/@microsoft.azure_autorest-core@2.0.4405/node_modules/@microsoft.azure/autorest-core/dist/app.js:33:5)
at emitOne (events.js:121:20)
at process.emit (events.js:211:7)
at process.emit (/node_modules/source-map-support/source-map-support.js:439:21)
fs.js:612
return binding.close(fd);
^
Error: EBADF: bad file descriptor, close
at Object.fs.closeSync (fs.js:612:18)
at StaticVolumeFile.shutdown (/opt/node_modules/autorest/dist/static-loader.js:352:10)
at StaticFilesystem.shutdown (/opt/node_modules/autorest/dist/static-loader.js:406:17)
at process.exit.n [as exit] (/opt/node_modules/autorest/dist/static-loader.js:169:11)
at printErrorAndExit (/node_modules/source-map-support/source-map-support.js:423:11)
at process.emit (/node_modules/source-map-support/source-map-support.js:435:16)
at process._fatalException (bootstrap_node.js:391:26) |
Latest improvements:
MSFT employees can try out our new experience at OpenAPI Hub - one location for using our validation tools and finding your workflow.
Contribution checklist:
ARM API Review Checklist
Failure to comply may result in delays for manifest application. Note this does not apply to data plane APIs.
Please follow the link to find more details on API review process.