[ec2] add_signal_on_exit_command uses incorrect stack-id causing stack timeout

[willruggiano]

https://github.com/aws/aws-cdk/blob/1293f6019143e693db2b1d25e648b326b719aeef/packages/%40aws-cdk/aws-ec2/lib/user-data.ts#L234

I'm using: NodeJS v12.14.1 cdk v1.34.1 (build 7b21aa0)

and writing my CDK apps in: Python v3.8.1 aws-cdk* == 1.35.0

---

When I use add_signal_on_exit_command, the command uses the synthesized stack name, which isn't always the same as the actual stack name (e.g. if I am just synthesizing a cloudformation template and then using it later to create multiple identical stacks). As a result the instance errors when calling cfn-signal: "stack ... does not exist" and the cloudformation stack eventually times out.

My personal workaround has been using the intrinsic core.Aws.STACK_ID to get the deploy-time stack-id, and implementing a custom "add_signal_on_exit_command".

[ericzbeard]

@willruggiano Can you confirm if this happens in the latest release?

[willruggiano]

@ericzbeard It sure does

[NetaNir]

I don't fully understand your use case, why would this be used in a decoupled way from the application synthesis?

If I am just synthesizing a cloudformation template and then using it later to create multiple identical stacks

Why would you not create multiple stacks using the CDK?

[willruggiano]

Well, yes. But not everyone uses the CDK that way. For example, I have a cli that my team uses to provision infrastructure for individual test purposes and it is not ideal to require every individual have the cdk installed locally, and to synthesize every time they deploy a new test environment (especially if synthesis implies, for example, docker bundling for lambda layers). Instead, we synthesize the templates while building the cli, package them into the distributable, and the cli uses them as it would any other “normal” template via cloudformation’s --template parameter. Now, I understand that the cdk’s modus operandi is fully self contained, synthesize-at-deploy-time templates but practically speaking this excludes a subset of customers from using the product as they would like to.

[NetaNir]

Got it. The CDK API is optimized for CDK workflow, especially for higher level features such as the cfn-signal. Probably the best path forward for your use case it to use the L1 layer. It's unlikely will support this in the future. Unless you think Im missing something, I suggest we close this issue.

[willruggiano]

Yeah, makes sense. Although, for these pseudo parameters it would not hurt (or break) anything to replace hardcoded values with pseudo parameter references. I'm talking about these; https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/pseudo-parameter-reference.html

They will resolve to the same values at deploy time regardless of how the CDK is being used.

[NetaNir]

We use pseudo parameter when possible, it's not always the case, for example when using assets the cdk needs to know the region account to publish to.

[NGL321]

It looks like this is clear to close, if this is in error please reopen and @ me to let me know!

😸 😷

[github-actions[bot]]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see. If you need more assistance, please either tag a team member or open a new issue that references this one. If you wish to keep having a conversation with other community members under this issue feel free to do so.