-
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
fix: UserPool, Volume, ElasticSearch, FSx are now RETAIN by default #12920
Conversation
Is it possible to tackle this specifically? I agree none of the options here are clearly better without downsides, but making it more obvious and less cumbersome to set |
Co-authored-by: Pat Myron <PatMyron@users.noreply.github.com>
@rix0rrr do we have some kind of enforcement/linting that future stateful resources also have a removal policy? |
@rix0rrr also - see aws/aws-cdk-rfcs#23 - perhaps would be useful to reference. |
Not at the moment, because it's not clear where that information should live. I suppose in the doc comments of each L2 is as good a place as any... though I'm not quite sure how linting and static analysis is going to help us verify (for example) default behavior. What we CAN do is say "if a resource has That's good as far as it goes, but just adding: class Resource {
/** get/set */
public removalPolicy: RemovalPolicy;
/* or this */
public applyRemovalPolicy(policy) {
(this.node.defaultChild as CfnResource).applyRemovalPolicy(policy);
}
} Is going to unlock the API for ALL resources, stateful or otherwise. Why wouldn't we do that instead? And if we have this, then the annotation and the forced Also, what is the point of the |
Where can we obtain a list of stateful resources? Does
The RFC issue is just a bunch of preliminary ideas. I wouldn't read too much into it. If I recall, the |
It does. We aren't really set up for this yet, but we could potentially start extending our L1 model with information from external sources such as cfnlint. The behavior I think would work is that we would mimic the same check cfn-lint would perform during validation: we can emit code for stateful L1s (as marked as such by cfn-lint) to require that they have a removal policy set. That doesn't force anyhthing about HOW the removal policy is set, but you will encounter this error while developing an L2 (while writing the unit tests for it) and the path of least resistance will be to just add that |
@rix0rrr sounds like a step in the right direction! |
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.
I've only reviewed the RDS part. LGTM.
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.
- ElasticSearch
- EKS
* @default RemovalPolicy.DESTROY | ||
*/ | ||
readonly removalPolicy?: RemovalPolicy; |
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.
You're sure this is the CF default, yeah?
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.
It is not. I've chosen to make this the default.
// eslint-disable-next-line no-console | ||
console.log(outFile); |
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.
stale from local dev?
// eslint-disable-next-line no-console | ||
console.log(outFile); |
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
@@ -0,0 +1,30 @@ | |||
{ | |||
"ResourceTypes": { |
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.
ow, this is a start of a new pattern.
Do we have guarantees from cfnlint about this file spec staying backwards compat? I'd hate for another round of dealing with breaking changes.
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.
Not really, but I don't see any way around that.
// Apply the loaded file as a patch onto the current structure | ||
patch(structure, data); |
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.
minor clarification - this the same patching mechanism as the cfn spec, yeah?
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.
Yes.
echo >&2 "Downloading from ${url}..." | ||
curl -sSfL "${url}" -o ${intermediate} | ||
|
||
for file in StatefulResources; do |
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.
minor: not familiar with this bash-ism: what is StatefulResources
?
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.
A literal string :D
tools/cfn2ts/lib/codegen.ts
Outdated
* ``` | ||
*/ | ||
private emitConstructValidator(resourceType: genspec.CodeName) { | ||
this.code.openBlock('protected validate(): string[]'); |
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.
Assume you're trying to use the validate API on construct compat layer. This is going away with v2 - https://github.com/aws/aws-cdk-rfcs/blob/master/text/0192-remove-constructs-compat.md#08-validation-the-validate-hook-is-now-nodeaddvalidation
Use addValidation()
instead, so we don't have to come back to fix this in v2.
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.
Did that, the types don't like it :(
@aws-cdk/core: �[96mlib/cloudformation.generated.ts�[0m:�[93m883�[0m:�[93m23�[0m - �[91merror�[0m�[90m TS2339: �[0mProperty 'addValidation' does not exist on type 'ConstructNode'.
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.
cc @eladb
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.
oh wait. Is this because this doesn't exist on constructs
pre-10.x?
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.
It does exist: https://github.com/aws/constructs/blob/117d3f1fee039eeac2d2aefa1b3e2d81530a63ff/src/construct.ts#L415
Use:
Node.of(x).addValidation()
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.
Please fix this - #12920 (comment)
Would also like to hear about the cfn-lint guarantee.
Otherwise looks good.
Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
(Gave this change an eye-catching title so it would stand out in the change log)
cfn-lint
expects all stateful resources to have a removal policy, but we weren't providing that option at the L2 level yet, and the L1 API is cumbersome.Add the
removalPolicy
option to the following resources:All L2 resources now have an
applyRemovalPolicy
method, so it can be set even for non-stateful resources.A mechanism has been added to the codegen so that new L2 authors cannot forget about the
removalPolicy
when they're writing an L2.I'm aware that the choice to make most of these RETAIN by default is going to be contentious. There are 2 questions here:
Is RETAIN the correct default?
I would argue "yes", by process of elimination:
Defaulting
removalPolicy
for all resources toDESTROY
if nothing is given (and writingDESTROY
to the template) is just going to put us back to the situation in CloudFormation beforecfn-lint
existed (your stateful resources are going to be destroyed and nothing is going to warn you about it).Making
removalPolicy
explicitly required for all stateful resources is a backwards-breaking change, and the point about CDK is that it will have sane defaults.I can't come up with a better solution than picking RETAIN as default.
Can we afford changing the default here?
I'm sensitive to the arguments that this a breaking change which we can't afford.
It feels like this is the value we would have given the resources had we thought about this earlier, and not being able to correct past mistakes by saying they are "locked in" is going to be a death knell for the project.
We could go for a "future behavior" flag, but the risk here seems minimal: this is a change that REDUCES risk of data loss. It might increase risk of deployment errors (duplicate resource names), but that can be manually managed. I will fast-follow with a change that will introduce warnings for resources that have a physical name set and also a RETAIN policy, to clearly identify you're doing something dangerous in CloudFormation. I'm not sure it's worth the effort to go further than that.
Although please: discussion welcome.
Fixes #12563.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license