-
Notifications
You must be signed in to change notification settings - Fork 4k
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
[efs] The default policy retains a resource #9270
Comments
Bug reports typically result from a distinction between a user's mental model and actual behavior. To bring this to the front and center, I like the phrasing: * Tell me what you expected to happen * Tell me what actually happened More than the current: * Paste code * See error The new phrasing subsumes the old one (what actually happened? I got an error) while also allowing to catch more bug-like scenarios. Hopefully it will prevent incomplete reports like this: #9270 where the user pasted in the code, didn't get an error so didn't fill out the "error" section, and didn't really state what they expected or saw happen.
Do you mean that you see Fairly sure that the default retention period for S3 is also RETAIN, and I think for RDS as well. I think we do this for most stateful resources. Do you mean there is no way to opt out of the retain behavior? |
Fortunately, you can opt out the default retain behaviour. What I notice (was under strong impression), that CF removes RDS, S3, etc when resource is created with default retain policy. Only, EFS requires manual clean-up or explicit definition of retain policy. |
It does, but CDK changes the default for these resources, for two reasons:
As for EFS resources, do you have qualms with the CDK default or the CFN default? Although for consistency's sake, we are most likely to keep the defaults the same as other stateful resources. |
When I said "CF removes" I mean if they are created via CDK.
but now, I see you point. yes, it is CfnFileSystem default one. I do not think we should do anything about it. |
Bug reports typically result from a distinction between a user's mental model and actual behavior. To bring this to the front and center, I like the phrasing: * Tell me what you expected to happen * Tell me what actually happened More than the current: * Paste code * See error The new phrasing subsumes the old one (what actually happened? I got an error) while also allowing to catch more bug-like scenarios. Hopefully it will prevent incomplete reports like this: #9270 where the user pasted in the code, didn't get an error so didn't fill out the "error" section, and didn't really state what they expected or saw happen. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Bug reports typically result from a distinction between a user's mental model and actual behavior. To bring this to the front and center, I like the phrasing: * Tell me what you expected to happen * Tell me what actually happened More than the current: * Paste code * See error The new phrasing subsumes the old one (what actually happened? I got an error) while also allowing to catch more bug-like scenarios. Hopefully it will prevent incomplete reports like this: #9270 where the user pasted in the code, didn't get an error so didn't fill out the "error" section, and didn't really state what they expected or saw happen. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Bug reports typically result from a distinction between a user's mental model and actual behavior. To bring this to the front and center, I like the phrasing: * Tell me what you expected to happen * Tell me what actually happened More than the current: * Paste code * See error The new phrasing subsumes the old one (what actually happened? I got an error) while also allowing to catch more bug-like scenarios. Hopefully it will prevent incomplete reports like this: aws#9270 where the user pasted in the code, didn't get an error so didn't fill out the "error" section, and didn't really state what they expected or saw happen. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
EFS uses inconsistent approach (with other modules) on the default removal policy. It retain the resource while other storage related modules removes them (e.g. RDS, S3, ...).
Reproduction Steps
Environment
The text was updated successfully, but these errors were encountered: