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.
|
|
rix0rrr
changed the title
| * | ||
| * 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.
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.
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.
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 <benisrae@amazon.com>
Co-authored-by: Elad Ben-Israel <benisrae@amazon.com>
Co-authored-by: Elad Ben-Israel <benisrae@amazon.com>
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.
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
rix0rrr
changed the title
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.
Seems the duplicate docs (readme + tsdoc) got out-of-sync during review/changes, e.g. this should be exportValue
ghost
self-assigned this
ghost
mentioned this pull request
…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*
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