Skip to content
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

Merged
merged 1 commit into from
Oct 31, 2019

Conversation

zfchen95
Copy link
Contributor

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:

  • I have reviewed the documentation for the workflow.
  • Validation tools were run on swagger spec(s) and have all been fixed in this PR.
  • The OpenAPI Hub was used for checking validation status and next steps.

ARM API Review Checklist

  • Service team MUST add the "WaitForARMFeedback" label if the management plane API changes fall into one of the below categories.
  • adding/removing APIs.
  • adding/removing properties.
  • adding/removing API-version.
  • adding a new service in Azure.

Failure to comply may result in delays for manifest application. Note this does not apply to data plane APIs.

  • If you are blocked on ARM review and want to get the PR merged urgently, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.
    Please follow the link to find more details on API review process.

@openapi-sdkautomation
Copy link

openapi-sdkautomation bot commented Oct 24, 2019

In Testing, Please Ignore

[Logs] (Generated from eb302b3, Iteration 2)

In-Progress .NET: test-repo-billy/azure-sdk-for-net [Logs]
  • Package generation in progress.
Pending Python: test-repo-billy/azure-sdk-for-python
  • Package generation pending.
In-Progress Java: test-repo-billy/azure-sdk-for-java [Logs]
  • Package generation in progress.
In-Progress Go: test-repo-billy/azure-sdk-for-go [Logs]
  • Package generation in progress.
Pending JavaScript: test-repo-billy/azure-sdk-for-js
  • Package generation pending.
Pending Ruby: test-repo-billy/azure-sdk-for-ruby
  • Package generation pending.

@zfchen95 zfchen95 changed the title [SRP] Add delete retention policy for blob container and file share [Do not merge][SRP] Add delete retention policy for blob container and file share Oct 24, 2019
@azuresdkci azuresdkci requested a review from yungezz October 24, 2019 21:59
@azuresdkci
Copy link
Contributor

Can one of the admins verify this patch?

@AutorestCI
Copy link

AutorestCI commented Oct 24, 2019

Automation for azure-sdk-for-go

The initial PR has been merged into your service PR:
Azure/azure-sdk-for-go#6200

@yungezz yungezz added the DoNotMerge <valid label in PR review process> use to hold merge after approval label Oct 25, 2019
@@ -1142,6 +1142,10 @@
"changeFeed": {
"$ref": "#/definitions/ChangeFeed",
"description": "The blob service properties for change feed events."
},
"containerDeleteRetentionPolicy": {
Copy link
Member

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

Copy link
Member

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

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.

Copy link
Member

@blueww blueww Oct 25, 2019

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.

Copy link
Contributor Author

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.

Copy link
Member

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.

Copy link
Member

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": {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same as above.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same as above.

@blueww
Copy link
Member

blueww commented Oct 25, 2019

@zfchen95
We also have the delete retention policy on Blob service properties. Why we still need it on blob container? Will the container policy overwrite the service policy?
Would you please give the feature doc link in the PR, so we can get more info for the feature, and can help the review.

@yungezz yungezz added the WaitForARMFeedback <valid label in PR review process> add this label when ARM review is required label Oct 25, 2019
@zfchen95
Copy link
Contributor Author

@zfchen95
We also have the delete retention policy on Blob service properties. Why we still need it on blob container? Will the container policy overwrite the service policy?
Would you please give the feature doc link in the PR, so we can get more info for the feature, and can help the review.

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.

@priyapansrp
Copy link

@zfchen95
We also have the delete retention policy on Blob service properties. Why we still need it on blob container? Will the container policy overwrite the service policy?
Would you please give the feature doc link in the PR, so we can get more info for the feature, and can help the review.

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.

@zfchen95 zfchen95 changed the title [Do not merge][SRP] Add delete retention policy for blob container and file share [SRP] Add delete retention policy for blob container and file share Oct 29, 2019
@zfchen95
Copy link
Contributor Author

@yungezz Could you remove the DoNotMerge tag. Thanks!

@zfchen95 zfchen95 requested a review from yungezz October 29, 2019 21:37
@pilor pilor added ARMReviewInProgress and removed DoNotMerge <valid label in PR review process> use to hold merge after approval labels Oct 30, 2019
@pilor pilor added ARMSignedOff <valid label in PR review process>add this label when ARM approve updates after review and removed ARMReviewInProgress WaitForARMFeedback <valid label in PR review process> add this label when ARM review is required labels Oct 30, 2019
@yungezz
Copy link
Member

yungezz commented Oct 31, 2019

hi @zfchen95 is the service change public? is the PR ready to merge?

@zfchen95
Copy link
Contributor Author

hi @zfchen95 is the service change public? is the PR ready to merge?

Hi @yungezz , you can merge this PR

@yungezz yungezz merged commit 0e99ef8 into Azure:master Oct 31, 2019
@AutorestCI
Copy link

AutorestCI commented Oct 31, 2019

Automation for azure-sdk-for-python

Encountered 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']
Finished with return code 7
and output:

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ARMSignedOff <valid label in PR review process>add this label when ARM approve updates after review
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants