adding purge protection vault property#2478
Conversation
Automation for azure-sdk-for-goA PR has been created for you based on this PR content. Once this PR will be merged, content will be added to your service PR: |
schaabs
left a comment
There was a problem hiding this comment.
The changes you have here look good, but you also need to update the examples createVault.json, getVault.json, and updateVault.json
|
I would prefer not to include this in the examples. Activating this property is irreversible and creates undeletable objects. The value of including it in the examples is marginal, whereas the effect can be quite confusing. Please consider this argument and let me know if you still think I should make that change. Thanks. (I could add separate files to exemplify soft delete/purge protection..) |
…perties, respectively. Updating examples with and without soft delete and purge protection flags.
Automation for azure-sdk-for-pythonA PR has been created for you: |
|
Hi There, I am the AutoRest Linter Azure bot. I am here to help. My task is to analyze the situation from the AutoRest linter perspective. Please review the below analysis result: File: AutoRest Linter Guidelines | AutoRest Linter Issues | Send feedback Thanks for your co-operation. |
|
After an offline discussion I agree this should not be added to the create and update examples. Changes look good to me. |
|
@sergey-shandar can we go ahead and merge these changes? |
|
@schaabs LGTM except it may introduce breaking changes for some SDKs. We also need ARM approval for this. @ravbhatnagar |
schaabs
left a comment
There was a problem hiding this comment.
@sergey-shandar you're right this is breaking. @dragav please see comments about property ordering
| "description": "Property to specify whether the 'soft delete' functionality is enabled for this key vault. It does not accept false value." | ||
| "description": "Property specifying whether recoverable deletion is enabled for this key vault. Setting this property to true activates the soft delete feature, whereby vaults or vault entities can be recovered after deletion. Enabling this functionality is irreversible - that is, the property does not accept false as its value." | ||
| }, | ||
| "enablePurgeProtection": { |
There was a problem hiding this comment.
This needs to be moved after create mode to avoid breaking changes in the sdk
| "description": "Property to specify whether the 'soft delete' functionality is enabled for this key vault. It does not accept false value." | ||
| "description": "Property specifying whether recoverable deletion ('soft' delete) is enabled for this key vault. The property may not be set to false." | ||
| }, | ||
| "enablePurgeProtection": { |
There was a problem hiding this comment.
This needs to be moved after create mode to avoid breaking changes in the sdk
|
Hi There, I am the AutoRest Linter Azure bot. I am here to help. My task is to analyze the situation from the AutoRest linter perspective. Please review the below analysis result: File: AutoRest Linter Guidelines | AutoRest Linter Issues | Send feedback Thanks for your co-operation. |
|
@ravbhatnagar are these changes ready to merge? |
|
@schaabs - Apologies but I dont follow. How does moving it after createMode make it non-breaking? |
|
@ravbhatnagar The breaking change I was referring to is not in the API itself but the clients generated by autorest. Adding the property before preexisting properties changes the order of parameters in the model constructors. So even though these are optional parameters, it breaks callers who don't specify the parameters by name, but only by order. Adding it after all the preexisting properties causes the generated code to have one more optional parameter at the end, so callers who don't specify this parameter will not break. |
|
@schaabs - Interesting, I wasnt aware of this. Anyhow, how will it impact the scenario where someone sets this property using the portal and then GETs this resource using an older SDK which ignores this property since it didnt understand it. Then does a PUT on the same resource, without this property in the payload. How does the value of this property on the server change? Does it get overwritten which could be unintentional from the user perspective in this case? |
|
@ravbhatnagar This is handled by the server behavior. This property can only be set on a vault once, and when set cannot be unset. This is documented in the description of the property "Enabling this functionality is irreversible". Once this property has been set, subsequent PUT operations which do not have the property specified will have no effect on the properties value. |
|
Signing off based on comments from @schaabs . it wont be an unintentional change as the service will handle it. |
This checklist is used to make sure that common issues in a pull request are addressed. This will expedite the process of getting your pull request merged and avoid extra work on your part to fix issues discovered during the review process.
PR information
api-versionin the path should match theapi-versionin the spec).Quality of Swagger