From 231b4e8f6e44bf43819e5db1982664cfc00839a0 Mon Sep 17 00:00:00 2001 From: epolon Date: Wed, 5 Jan 2022 18:05:26 +0200 Subject: [PATCH 1/8] mid work --- text/stateful-resources-one-pager.md | 55 ++++++++++++++++++++++++++++ 1 file changed, 55 insertions(+) create mode 100644 text/stateful-resources-one-pager.md diff --git a/text/stateful-resources-one-pager.md b/text/stateful-resources-one-pager.md new file mode 100644 index 000000000..9ac599600 --- /dev/null +++ b/text/stateful-resources-one-pager.md @@ -0,0 +1,55 @@ +# 1Pager | Modeling Stateful Resources + +This document is a one pager meant to surface the idea of explicitly modeling stateful resources in the core framework. Its goal is to conduct a preliminary discussion and gather feedback before it potentially progresses into a full blown RFC. + +## Customer pain + +Customers are currently exposed to un intentional data loss when stateful resources are designated for either removal or replacement by CloudFormation. + +Data, similarly to security postures, is an area in which even a single rare mistake can cause catastrophic outages. The CDK can and should help reduce the risk of such failures. +With respect to security, the CDK currently defaults to blocking deployments that contain changes in security postures, requiring a user confirmation: + +```console +(NOTE: There may be security-related changes not in this list. See https://github.com/aws/aws-cdk/issues/1299) + +Do you wish to deploy these changes (y/n)? +``` + +However, no such mechanism exists for changes that might result in data loss, i.e removal or replacement of stateful resources, such as `S3` buckets, `DynamoDB` tables, etc... + +## Failure scenarios + +To understand how susceptible customers are to this, we outline a few scenarios where such data loss can occur. + +### Stateful resource without `DeletionPolicy/UpdateReplacePolicy` + +By default, CloudFormation will **delete** resources that are removed from the stack, or when a property that requires replacement is changed. + +> - [UpdateReplacePolicy](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-attribute-updatereplacepolicy.html) +> - [DeletionPolicy](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-attribute-deletionpolicy.html) + +To retain stateful resources, authors must remember to configure those policies with the `Retain` value. Having to remember this makes it also easy to forget. This means that stateful resources might be shipped with the incorrect policy. + +### Policy Change + +CDK applications are often comprised out of many third-party resources. Even if a third-party resource is initially shipped with the correct policy, this may change. Whether or not the policy change was intentional is somewhat irrelevant, it can still be undesired and have dire implications on the consuming application. + +For that matter, even policy changes made by the application author itself can be unexpected or undesired. + +## Proposal + +The proposal described here was designed under the following assumptions: + +1. The correct policy for stateful resources is always `Retain`. +2. Its better + +## Q & A + +#### Isn't remembering to extend `StatefulResource` the same as remembering to configure `DeletionPolicy/UpdateReplacePolicy`? + +#### What about CDK Pipelines? + +#### Would this have prevented https://github.com/aws/aws-cdk/issues/16603 ? + +#### + From 95d66f96904a79077edee40ffa026c61f03614c1 Mon Sep 17 00:00:00 2001 From: epolon Date: Wed, 5 Jan 2022 21:24:21 +0200 Subject: [PATCH 2/8] mid work --- text/stateful-resources-one-pager.md | 105 +++++++++++++++++++++++++-- 1 file changed, 98 insertions(+), 7 deletions(-) diff --git a/text/stateful-resources-one-pager.md b/text/stateful-resources-one-pager.md index 9ac599600..d930bab98 100644 --- a/text/stateful-resources-one-pager.md +++ b/text/stateful-resources-one-pager.md @@ -10,8 +10,10 @@ Data, similarly to security postures, is an area in which even a single rare mis With respect to security, the CDK currently defaults to blocking deployments that contain changes in security postures, requiring a user confirmation: ```console -(NOTE: There may be security-related changes not in this list. See https://github.com/aws/aws-cdk/issues/1299) - +This deployment will make potentially sensitive changes according to your current security approval level (--require-approval broadening). +Please confirm you intend to make the following modifications: +... +... Do you wish to deploy these changes (y/n)? ``` @@ -36,12 +38,101 @@ CDK applications are often comprised out of many third-party resources. Even if For that matter, even policy changes made by the application author itself can be unexpected or undesired. -## Proposal +## Desired Customer Experience -The proposal described here was designed under the following assumptions: +The experience described here lays under the following assumptions: 1. The correct policy for stateful resources is always `Retain`. -2. Its better +2. With data loss, its better to ask for permission than ask for forgiveness. + +As mentioned before, we should provide an experience similar to the one we have with respect to security posture changes. When deploying or destroying an application causes the removal of stateful resources, the user will, by default, see: + +```console +The following stateful resources will be removed: + + - MyBucket (Removed from stack) + - MyDynamoTable (Changing property `TableName` requires a replacement) + +Do you wish to continue (y/n)? +``` + +> Note that we want to warn the users about possible replacements as well, not just removals. + +If this is desired, the user will confirm. And if this behavior is expected to repeat, the user can run: + +`cdk deploy --allow-removal MyBucket --allow-removal MyDynamoTable` + +To skip the interactive confirmation. + +An additional feature we can provide is to detect when a deployment will change the policy of stateful resources. i.e: + +```console +The removal policy of the following stateful resources will change: + + - MyBucket (RETAIN -> DESTROY) + - MyDynamoTable (RETAIN -> DESTROY) + +Do you wish to continue (y/n)? +``` + +Blocking these types of changes will keep the CloudFormation template in a safe state. +Otherwise, if such changes are allowed to be deployed, out of band operations +via CloudFormation will still pose a risk. + +## High Level Design + +In order to provide any of the features described above, the core framework must be able +to differentiate between stateful and stateless resources. This means we need to enforce that every +resource marks itself as such. + +We propose to add the following properties to the `CfnResourceProps` interface: + +```ts +export interface CfnResourceProps { + /** + * Whether or not this resource is stateful. + */ + readonly stateful: boolean; + + /** + * Which properties cause replacement of this resource. + * Required if the resource is stateful, encouraged otherwise. + * + * @default undefined + */ + readonly replacedIf?: string[]; +} +``` + +In addition, we manually curate a list of stateful resources and check that into our source code, i.e: + ++ stateful-resources.json + +```json +{ + "AWS::S3::Bucket": ["BucketName"], + "AWS::DynamoDB::Table": ["TableName"], +} +``` + +The key is the resource type, and the value is the list of properties that require replacement. +This file will be used during execution of `cfn2ts` so that every resource passes the right values for these new properties. For example: + +```ts +export class CfnBucket extends cdk.CfnResource implements cdk.IInspectable { + + constructor(scope: cdk.Construct, id: string, props: CfnBucketProps = {}) { + super(scope, id, { + stateful: true, + replacedIf: ["BucketName"], + type: CfnBucket.CFN_RESOURCE_TYPE_NAME, + properties: props + }); + ... + ... + } +} +``` ## Q & A @@ -49,7 +140,7 @@ The proposal described here was designed under the following assumptions: #### What about CDK Pipelines? -#### Would this have prevented https://github.com/aws/aws-cdk/issues/16603 ? +#### Would this have prevented https://github.com/aws/aws-cdk/issues/16603? -#### +#### From b0b5a0bb4bba145caac7cfcd17ed0e4c5c63728e Mon Sep 17 00:00:00 2001 From: epolon Date: Wed, 5 Jan 2022 22:22:05 +0200 Subject: [PATCH 3/8] mid work --- text/stateful-resources-one-pager.md | 32 +++++++++++++++++++++++----- 1 file changed, 27 insertions(+), 5 deletions(-) diff --git a/text/stateful-resources-one-pager.md b/text/stateful-resources-one-pager.md index d930bab98..25a2958d2 100644 --- a/text/stateful-resources-one-pager.md +++ b/text/stateful-resources-one-pager.md @@ -82,10 +82,15 @@ via CloudFormation will still pose a risk. ## High Level Design In order to provide any of the features described above, the core framework must be able -to differentiate between stateful and stateless resources. This means we need to enforce that every -resource marks itself as such. +to differentiate between stateful and stateless resources. -We propose to add the following properties to the `CfnResourceProps` interface: +> Side note: Explicitly differentiating stateful resources from stateless ones is a common practice in infrastructure modeling. For example, Kubernetes uses the [`StatefulSet`](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/) resource for this. And terraform has the [`prevent_destroy`](https://www.terraform.io/language/meta-arguments/lifecycle#prevent_destroy) property to mark stateful resources. + +### API + +We'd like to extend our API so it enforces every resource marks itself as either stateful or stateless. + +To that end, we propose adding the following properties to the `CfnResourceProps` interface: ```ts export interface CfnResourceProps { @@ -104,7 +109,12 @@ export interface CfnResourceProps { } ``` -In addition, we manually curate a list of stateful resources and check that into our source code, i.e: +### CodeGen + +Adding those properties will break the generated L1 resources because the `stateful` property is required. +This means we need to add some logic into `cfn2ts` so that it generates constructors that pass the appropriate values. + +To support this, we manually curate a list of stateful resources and check that into our source code, i.e: + stateful-resources.json @@ -116,7 +126,11 @@ In addition, we manually curate a list of stateful resources and check that into ``` The key is the resource type, and the value is the list of properties that require replacement. -This file will be used during execution of `cfn2ts` so that every resource passes the right values for these new properties. For example: + +> We might be able to leverage the work already done by cfn-lint: [StatefulResources.json](https://github.com/aws-cloudformation/cfn-lint/blob/main/src/cfnlint/data/AdditionalSpecs/StatefulResources.json) +> However, we also need the list of properties that require replacement for these resources. We can probably collaborate with cfn-lint on this. + +Using this file, we can generate the correct constructor, for example: ```ts export class CfnBucket extends cdk.CfnResource implements cdk.IInspectable { @@ -134,6 +148,14 @@ export class CfnBucket extends cdk.CfnResource implements cdk.IInspectable { } ``` +### Synthesis + +### Deployment + + + + + ## Q & A #### Isn't remembering to extend `StatefulResource` the same as remembering to configure `DeletionPolicy/UpdateReplacePolicy`? From 3d250bf71d3f9bd8f4c39dff2b9c2386d43bca1f Mon Sep 17 00:00:00 2001 From: epolon Date: Wed, 5 Jan 2022 23:04:07 +0200 Subject: [PATCH 4/8] mid work --- text/stateful-resources-one-pager.md | 129 ++++++++++++++++++++------- 1 file changed, 99 insertions(+), 30 deletions(-) diff --git a/text/stateful-resources-one-pager.md b/text/stateful-resources-one-pager.md index 25a2958d2..4a8838ee6 100644 --- a/text/stateful-resources-one-pager.md +++ b/text/stateful-resources-one-pager.md @@ -1,13 +1,17 @@ # 1Pager | Modeling Stateful Resources -This document is a one pager meant to surface the idea of explicitly modeling stateful resources in the core framework. Its goal is to conduct a preliminary discussion and gather feedback before it potentially progresses into a full blown RFC. +This document is a one pager meant to surface the idea of explicitly modeling +stateful resources in the core framework. Its goal is to conduct a preliminary +discussion and gather feedback before it potentially progresses into a full blown RFC. ## Customer pain Customers are currently exposed to un intentional data loss when stateful resources are designated for either removal or replacement by CloudFormation. -Data, similarly to security postures, is an area in which even a single rare mistake can cause catastrophic outages. The CDK can and should help reduce the risk of such failures. -With respect to security, the CDK currently defaults to blocking deployments that contain changes in security postures, requiring a user confirmation: +Data, similarly to security postures, is an area in which even a single rare +mistake can cause catastrophic outages. The CDK can and should help reduce the risk +of such failures. With respect to security, the CDK currently defaults to +blocking deployments that contain changes in security postures, requiring a user confirmation: ```console This deployment will make potentially sensitive changes according to your current security approval level (--require-approval broadening). @@ -17,26 +21,35 @@ Please confirm you intend to make the following modifications: Do you wish to deploy these changes (y/n)? ``` -However, no such mechanism exists for changes that might result in data loss, i.e removal or replacement of stateful resources, such as `S3` buckets, `DynamoDB` tables, etc... +However, no such mechanism exists for changes that might result in data loss, +i.e removal or replacement of stateful resources, such as `S3` buckets, `DynamoDB` tables, etc... ## Failure scenarios -To understand how susceptible customers are to this, we outline a few scenarios where such data loss can occur. +To understand how susceptible customers are to this, we outline a few +scenarios where such data loss can occur. ### Stateful resource without `DeletionPolicy/UpdateReplacePolicy` -By default, CloudFormation will **delete** resources that are removed from the stack, or when a property that requires replacement is changed. +By default, CloudFormation will **delete** resources that are removed from the stack, +or when a property that requires replacement is changed. > - [UpdateReplacePolicy](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-attribute-updatereplacepolicy.html) > - [DeletionPolicy](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-attribute-deletionpolicy.html) -To retain stateful resources, authors must remember to configure those policies with the `Retain` value. Having to remember this makes it also easy to forget. This means that stateful resources might be shipped with the incorrect policy. +To retain stateful resources, authors must remember to configure those policies +with the `Retain` value. Having to remember this makes it also easy to forget. +This means that stateful resources might be shipped with the incorrect policy. ### Policy Change -CDK applications are often comprised out of many third-party resources. Even if a third-party resource is initially shipped with the correct policy, this may change. Whether or not the policy change was intentional is somewhat irrelevant, it can still be undesired and have dire implications on the consuming application. +CDK applications are often comprised out of many third-party resources. +Even if a third-party resource is initially shipped with the correct policy, this may change. +Whether or not the policy change was intentional is somewhat irrelevant, it can +still be undesired and have dire implications on the consuming application. -For that matter, even policy changes made by the application author itself can be unexpected or undesired. +For that matter, even policy changes made by the application author itself +can be unexpected or undesired. ## Desired Customer Experience @@ -45,7 +58,9 @@ The experience described here lays under the following assumptions: 1. The correct policy for stateful resources is always `Retain`. 2. With data loss, its better to ask for permission than ask for forgiveness. -As mentioned before, we should provide an experience similar to the one we have with respect to security posture changes. When deploying or destroying an application causes the removal of stateful resources, the user will, by default, see: +As mentioned before, we should provide an experience similar to the one we have +with respect to security posture changes. When deploying or destroying an +application causes the removal of stateful resources, the user will, by default, see: ```console The following stateful resources will be removed: @@ -84,13 +99,17 @@ via CloudFormation will still pose a risk. In order to provide any of the features described above, the core framework must be able to differentiate between stateful and stateless resources. -> Side note: Explicitly differentiating stateful resources from stateless ones is a common practice in infrastructure modeling. For example, Kubernetes uses the [`StatefulSet`](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/) resource for this. And terraform has the [`prevent_destroy`](https://www.terraform.io/language/meta-arguments/lifecycle#prevent_destroy) property to mark stateful resources. +> **Side note**: Explicitly differentiating stateful resources from stateless ones is a +> common practice in infrastructure modeling. For example, Kubernetes +> uses the [`StatefulSet`](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/) +> resource for this. +> And terraform has the [`prevent_destroy`](https://www.terraform.io/language/meta-arguments/lifecycle#prevent_destroy) property to mark stateful resources. ### API -We'd like to extend our API so it enforces every resource marks itself as either stateful or stateless. - -To that end, we propose adding the following properties to the `CfnResourceProps` interface: +We'd like to extend our API so it enforces every resource marks itself as either +stateful or stateless. To that end, we propose adding the following properties to +the `CfnResourceProps` interface: ```ts export interface CfnResourceProps { @@ -109,15 +128,36 @@ export interface CfnResourceProps { } ``` -### CodeGen +As well as corresponding getters: + +```ts +/** + * Represents a CloudFormation resource. + */ +export class CfnResource extends CfnRefElement { -Adding those properties will break the generated L1 resources because the `stateful` property is required. -This means we need to add some logic into `cfn2ts` so that it generates constructors that pass the appropriate values. + public get stateful: boolean; -To support this, we manually curate a list of stateful resources and check that into our source code, i.e: + public get replacedIf?: string[]; + + constructor(scope: Construct, id: string, props: CfnResourceProps) { + super(scope, id); + this.stateful = props.stateful; + this.replacedIf = props.replacedIf; + } +} +``` + +### CodeGen + +Adding these properties will break the generated L1 resources. We need to add some +logic into `cfn2ts` so that it generates constructors that pass the appropriate values. +For that, we manually curate a list of stateful resources and check that into our source code, i.e: + stateful-resources.json +> The key is the resource type, and the value is the list of properties that require replacement. + ```json { "AWS::S3::Bucket": ["BucketName"], @@ -125,11 +165,6 @@ To support this, we manually curate a list of stateful resources and check that } ``` -The key is the resource type, and the value is the list of properties that require replacement. - -> We might be able to leverage the work already done by cfn-lint: [StatefulResources.json](https://github.com/aws-cloudformation/cfn-lint/blob/main/src/cfnlint/data/AdditionalSpecs/StatefulResources.json) -> However, we also need the list of properties that require replacement for these resources. We can probably collaborate with cfn-lint on this. - Using this file, we can generate the correct constructor, for example: ```ts @@ -142,27 +177,61 @@ export class CfnBucket extends cdk.CfnResource implements cdk.IInspectable { type: CfnBucket.CFN_RESOURCE_TYPE_NAME, properties: props }); - ... - ... } } ``` ### Synthesis +Now that all L1 resources are correctly marked and can be inspected, we add +logic to the synthesis process to write this metadata to the cloud assembly. +For example, a stack called `my-stack`, defining an `S3` bucket with +id `MyBucket`, will contain the following in `manifest.json`: + +```json +{ + "metadata": { + "/my-stack/MyBucket/Resource": [ + { + "stateful": true, + "replacedIf": ["BucketName"], + } + ], + } +} +``` + ### Deployment +During deployment, we inspect the diff and identify which changes are about +to occur on stateful resources in the stack. This closes the loop and should +allow for the [customer experience](#desired-customer-experience) we described. + +## Q & A +### Why do we need the API change given we have the curated file? +Its true that the existence of the file allows us to codegen marked L1 resources +without needing to make changes to the input API. However, this won't +cover the use-case of **stateful custom resources**. As we know, custom resources may +also be stateful. This scenario is in fact what sparked this discussion. +> See [s3: toggling off auto_delete_objects for Bucket empties the bucket](https://github.com/aws/aws-cdk/issues/16603) -## Q & A +Since every [`CustomResource`] eventually instantiates a `CfnResource`, +changing this API will also enforce that every custom resource is marked, +which is the desired behavior. -#### Isn't remembering to extend `StatefulResource` the same as remembering to configure `DeletionPolicy/UpdateReplacePolicy`? +In addition, enforcing this on the API level will also be beneficial for third-party +constructs that might be extending from `CfnResource`. -#### What about CDK Pipelines? +[CustomResource]: https://github.com/aws/aws-cdk/blob/master/packages/@aws-cdk/core/lib/custom-resource.ts#L123 -#### Would this have prevented https://github.com/aws/aws-cdk/issues/16603? +### What about CDK Pipelines? -#### +### Would this have prevented [#16603](https://github.com/aws/aws-cdk/issues/16603)? +### Curating a list of stateful resources is a maintenance burden - can we do it differently? + +> We might be able to leverage the work already done by cfn-lint: [StatefulResources.json](https://github.com/aws-cloudformation/cfn-lint/blob/main/src/cfnlint/data/AdditionalSpecs/StatefulResources.json) +> However, we also need the list of properties that require replacement for these resources. We can probably collaborate with cfn-lint on this. From 8e98f06c840a513b734c6ba90785d625c8b0e68f Mon Sep 17 00:00:00 2001 From: epolon Date: Wed, 5 Jan 2022 23:13:56 +0200 Subject: [PATCH 5/8] mid work --- text/stateful-resources-one-pager.md | 20 +++++++++++++++----- 1 file changed, 15 insertions(+), 5 deletions(-) diff --git a/text/stateful-resources-one-pager.md b/text/stateful-resources-one-pager.md index 4a8838ee6..0efaa8f75 100644 --- a/text/stateful-resources-one-pager.md +++ b/text/stateful-resources-one-pager.md @@ -218,9 +218,8 @@ also be stateful. This scenario is in fact what sparked this discussion. > See [s3: toggling off auto_delete_objects for Bucket empties the bucket](https://github.com/aws/aws-cdk/issues/16603) -Since every [`CustomResource`] eventually instantiates a `CfnResource`, -changing this API will also enforce that every custom resource is marked, -which is the desired behavior. +Since every [CustomResource] eventually instantiates a `CfnResource`, +changing this API will also make sure custom resources are marked appropriately. In addition, enforcing this on the API level will also be beneficial for third-party constructs that might be extending from `CfnResource`. @@ -229,9 +228,20 @@ constructs that might be extending from `CfnResource`. ### What about CDK Pipelines? +This document only refers to a deployment workflow using `cdk deploy`. I have yet +to research how this would be done in CDK pipelines. My initial thoughts are to somehow incorporate +`cdk diff` in the pipeline, along with a manual approval stage. + ### Would this have prevented [#16603](https://github.com/aws/aws-cdk/issues/16603)? +Yes. If the API proposed here existed, we would have passed `stateful: true` in the +implementation of the `autoDeleteObjects` property. Then, when the resource was +removed due to the toggle, we would identify this as a removal of a stateful resource, and block it. + ### Curating a list of stateful resources is a maintenance burden - can we do it differently? -> We might be able to leverage the work already done by cfn-lint: [StatefulResources.json](https://github.com/aws-cloudformation/cfn-lint/blob/main/src/cfnlint/data/AdditionalSpecs/StatefulResources.json) -> However, we also need the list of properties that require replacement for these resources. We can probably collaborate with cfn-lint on this. +We might be able to leverage the work already done by cfn-lint, i.e [StatefulResources.json]. +However, we also need the list of properties that require replacement for these resources. +We can probably collaborate with cfn-lint on this. + +[StatefulResources.json]: https://github.com/aws-cloudformation/cfn-lint/blob/main/src/cfnlint/data/AdditionalSpecs/StatefulResources.json From c5d463a4d3ad72872f603813084238ecd87a8574 Mon Sep 17 00:00:00 2001 From: epolon Date: Wed, 5 Jan 2022 23:22:27 +0200 Subject: [PATCH 6/8] mid work --- text/stateful-resources-one-pager.md | 23 ++++++++++++----------- 1 file changed, 12 insertions(+), 11 deletions(-) diff --git a/text/stateful-resources-one-pager.md b/text/stateful-resources-one-pager.md index 0efaa8f75..13c2462ca 100644 --- a/text/stateful-resources-one-pager.md +++ b/text/stateful-resources-one-pager.md @@ -6,12 +6,14 @@ discussion and gather feedback before it potentially progresses into a full blow ## Customer pain -Customers are currently exposed to un intentional data loss when stateful resources are designated for either removal or replacement by CloudFormation. +Customers are currently exposed to unintentional data loss when stateful resources +are designated for either removal or replacement by CloudFormation. Data, similarly +to security postures, is an area in which even a single rare mistake can +cause catastrophic outages. -Data, similarly to security postures, is an area in which even a single rare -mistake can cause catastrophic outages. The CDK can and should help reduce the risk -of such failures. With respect to security, the CDK currently defaults to -blocking deployments that contain changes in security postures, requiring a user confirmation: +The CDK can and should help reduce the risk of such failures. With respect to +security, the CDK currently defaults to blocking deployments that contain +changes in security postures, requiring a user confirmation: ```console This deployment will make potentially sensitive changes according to your current security approval level (--require-approval broadening). @@ -59,8 +61,8 @@ The experience described here lays under the following assumptions: 2. With data loss, its better to ask for permission than ask for forgiveness. As mentioned before, we should provide an experience similar to the one we have -with respect to security posture changes. When deploying or destroying an -application causes the removal of stateful resources, the user will, by default, see: +with respect to security posture changes. We propose that when deploying or +destroying a stack, in case it causes the removal of stateful resources, the user will see: ```console The following stateful resources will be removed: @@ -73,12 +75,11 @@ Do you wish to continue (y/n)? > Note that we want to warn the users about possible replacements as well, not just removals. -If this is desired, the user will confirm. And if this behavior is expected to repeat, the user can run: +If this is desired, the user will confirm. And if this behavior is expected to repeat, +the user can use a new `allow-removal` flag, to skip the interactive confirmation: `cdk deploy --allow-removal MyBucket --allow-removal MyDynamoTable` -To skip the interactive confirmation. - An additional feature we can provide is to detect when a deployment will change the policy of stateful resources. i.e: ```console @@ -90,7 +91,7 @@ The removal policy of the following stateful resources will change: Do you wish to continue (y/n)? ``` -Blocking these types of changes will keep the CloudFormation template in a safe state. +Blocking these types of changes will keep CloudFormation templates in a safe state. Otherwise, if such changes are allowed to be deployed, out of band operations via CloudFormation will still pose a risk. From 5d49c27f691e8d9bda1773b0a83442359efe698b Mon Sep 17 00:00:00 2001 From: epolon Date: Thu, 6 Jan 2022 11:56:38 +0200 Subject: [PATCH 7/8] one more q --- text/stateful-resources-one-pager.md | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/text/stateful-resources-one-pager.md b/text/stateful-resources-one-pager.md index 13c2462ca..db55e2452 100644 --- a/text/stateful-resources-one-pager.md +++ b/text/stateful-resources-one-pager.md @@ -246,3 +246,13 @@ However, we also need the list of properties that require replacement for these We can probably collaborate with cfn-lint on this. [StatefulResources.json]: https://github.com/aws-cloudformation/cfn-lint/blob/main/src/cfnlint/data/AdditionalSpecs/StatefulResources.json + +### Isn't this a breaking change? How are we supposed to roll it out? + +Yes. Making the `stateful` property required will break some customers. +There are two options I can think of: + +1. Release it as v3. We should in general consider not being so hesitant about releasing new major versions. +We've seen with v2 that as long as migrations are not too painful, our customers are willing to +perform such upgrades. +2. Make the `stateful` property optional and perform runtime validations controlled by a feature flag. \ No newline at end of file From 5059d26ad1bbb00f5ae59214132b7f14a333b096 Mon Sep 17 00:00:00 2001 From: epolon Date: Thu, 6 Jan 2022 13:12:18 +0200 Subject: [PATCH 8/8] lint --- text/stateful-resources-one-pager.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/stateful-resources-one-pager.md b/text/stateful-resources-one-pager.md index db55e2452..94d5b9396 100644 --- a/text/stateful-resources-one-pager.md +++ b/text/stateful-resources-one-pager.md @@ -255,4 +255,4 @@ There are two options I can think of: 1. Release it as v3. We should in general consider not being so hesitant about releasing new major versions. We've seen with v2 that as long as migrations are not too painful, our customers are willing to perform such upgrades. -2. Make the `stateful` property optional and perform runtime validations controlled by a feature flag. \ No newline at end of file +2. Make the `stateful` property optional and perform runtime validations controlled by a feature flag.