-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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
feat(core): stack.exportValue()
can be used to solve "deadly embrace"
#12778
Conversation
"Deadly embrace" is a great term but an annoying problem. The best way to work around it is to manually ensure the CloudFormation Export exists while you remove the consuming relationship. Adam has a blog post about this, but the mechanism can be more smooth. Add a method, `stack.exportAttribute(...)` which can be used to create the Export for the duration of the deployment that breaks the relationship, and add an explanation of how to use it. Fixes #7602.
* | ||
* In case of a string, the string must not be a concatenation. | ||
*/ | ||
public static reverse(x: any): IResolvable | undefined { |
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 am not 100% sure this has tons of value as a public API. Can we make it internal for now?
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. If we want to use it in other modules, it needs to be public (Adam's needed this when implementing a guard that reverses Tokens in CodeBuild, but ended up reimplementing himself).
Plus, it seems only fair that if the API to encode a token to a literal is public, the API to reverse that encoding should also be public.
packages/@aws-cdk/core/README.md
Outdated
@@ -92,6 +92,36 @@ nested stack and referenced using `Fn::GetAtt "Outputs.Xxx"` from the parent. | |||
|
|||
Nested stacks also support the use of Docker image and file assets. | |||
|
|||
### Breaking automatic references |
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.
Feels like this should be part of the section that describes cross references in the dev guide.
Maybe we can copy the contents from the dev guide to here and just add this as a subsection? And then also duplicate this to the dev guide?
Co-authored-by: Elad Ben-Israel <[email protected]>
Co-authored-by: Elad Ben-Israel <[email protected]>
Co-authored-by: Elad Ben-Israel <[email protected]>
packages/@aws-cdk/core/lib/stack.ts
Outdated
* - Don't forget to remove the `exportAttribute()` call as well. | ||
* - Deploy again (this time only the `producerStack` will be changed -- the bucket will be deleted). | ||
*/ | ||
public exportAttribute(exportedAttribute: any) { |
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.
As discussed, I am wondering if we can make this slightly more generic and resolve #2036 along the way:
const importValue = stack.exportValue(attribute); // auto-name
const importValue = stack.exportValue(1234, { name: 'my-export-name' }); // since the value is not an attribute `name` is required
stack.exportValue()
can be used to solve "deadly embrace"
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). |
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 |
- Make sure `stack2` no longer references `bucket.bucketName` (maybe the consumer | ||
stack now uses its own bucket, or it writes to an AWS DynamoDB table, or maybe you just | ||
remove the Lambda Function altogether). | ||
- In the `stack1` class, call `this.exportAttribute(this.bucket.bucketName)`. This |
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.
Seems the duplicate docs (readme + tsdoc) got out-of-sync during review/changes, e.g. this should be exportValue
…e" (aws#12778) Deadly embrace (<3 who came up with this term) is an issue where a consumer stack depends on a producer stack via CloudFormation Exports, and you want to remove the use from the consumer. Removal of the resource sharing implicitly removes the CloudFormation Export, but now CloudFormation won't let you deploy that because the deployment order is always forced to be (1st) producer (2nd) consumer, and when the producer deploys and tries to remove the Export, the consumer is still using it. The best way to work around it is to manually ensure the CloudFormation Export exists while you remove the consuming relationship. @skinny85 has a [blog post] about this, but the mechanism can be more smooth. Add a method, `stack.exportValue(...)` which can be used to create the Export for the duration of the deployment that breaks the relationship, and add an explanation of how to use it. Genericize the method a bit so it also solves a long-standing issue about no L2 support for exports. Fixes aws#7602, fixes aws#2036. [blog post]: https://www.endoflineblog.com/cdk-tips-03-how-to-unblock-cross-stack-references ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
CDK has a limitation where if you attempt to remove all references to a resource from another stack, CDK will attempt to remove the export for that resource, which then fails because it sees there is still an external dependency on that resource, creating a 'deadly embrace' See aws/aws-cdk#12778. The workaround for this is to set dummy export values to trick CDK into keeping the unused exports around until you've deployed your updates to the dependent stack.
CDK has a limitation where if you attempt to remove all references to a resource from another stack, CDK will attempt to remove the export for that resource, which then fails because it sees there is still an external dependency on that resource, creating a 'deadly embrace' See aws/aws-cdk#12778. The workaround for this is to set dummy export values to trick CDK into keeping the unused exports around until you've deployed your updates to the dependent stack.
CDK has a limitation where if you attempt to remove all references to a resource from another stack, CDK will attempt to remove the export for that resource, which then fails because it sees there is still an external dependency on that resource, creating a 'deadly embrace' See aws/aws-cdk#12778. The workaround for this is to set dummy export values to trick CDK into keeping the unused exports around until you've deployed your updates to the dependent stack.
CDK has a limitation where if you attempt to remove all references to a resource from another stack, CDK will attempt to remove the export for that resource, which then fails because it sees there is still an external dependency on that resource, creating a 'deadly embrace' See aws/aws-cdk#12778. The workaround for this is to set dummy export values to trick CDK into keeping the unused exports around until you've deployed your updates to the dependent stack.
Deadly embrace (<3 who came up with this term) is an issue where a consumer
stack depends on a producer stack via CloudFormation Exports, and you want to
remove the use from the consumer.
Removal of the resource sharing implicitly removes the CloudFormation Export,
but now CloudFormation won't let you deploy that because the deployment order
is always forced to be (1st) producer (2nd) consumer, and when the producer deploys
and tries to remove the Export, the consumer is still using it.
The best way to work around it is to manually ensure the CloudFormation Export
exists while you remove the consuming relationship. @skinny85 has a blog
post about this, but the mechanism can be more smooth.
Add a method,
stack.exportValue(...)
which can be used tocreate the Export for the duration of the deployment that breaks
the relationship, and add an explanation of how to use it.
Genericize the method a bit so it also solves a long-standing issue about no L2 support for exports.
Fixes #7602, fixes #2036.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license