From Terraform to CDK - Unique ID

[ghost]

Hi,

I worked a bit on the CDK, and I was wondering of how to migrate existing Terraform to CDK.

The CDK generate a unique ID for each resource/module. But this behavior may be good for new infrastructure, but not for existing one. Why this behavior ?

Thanks,

[skorfmann]

Hey @benoitmenard-richemont - thanks, that's a great question!

I worked a bit on the CDK, and I was wondering of how to migrate existing Terraform to CDK.

There's a feature request to handle this particular case #248

A bit of background:

One of the core ideas of the CDK is to have layered abstractions for your resources. What we generate with cdktf get is essentially just a mapping layer for the actual Terraform resources - or in CDK terms a Level 1 resource. A Level 2 resource, would be a handcrafted abstraction which builds upon the Level 1 resources and enriches them with intent driven apis. You see where this going: The higher the Level, the more abstract it gets.

To some extent, this is similar to what you could do with Terraform modules. However, cdktf is not using Terraform modules, but is working in the root namespace only. Since you could pull in Level 2 / 3 abstractions which could contain lots of deeply nested resources, we need a way to guarantee unique resource names within a given stack (which is ultimately a tree of resources)

At the moment, this is done via:

• Reflecting the name of all ancestors of the given node in the resource tree
• Appending a hash of the former to that name

The naming logic is stemming from the AWS CDK (Cloudformation) where there's a hard limit (255 characters) on resource names. The actual name will be cut at 240 characters, and then a hash of the full name will be appended to still ensure uniqueness.

As you might think: Well, does this apply to Terraform? At least when it comes to the length restrictions it doesn't. I don't have an exact upper limit, but I just planned a resource with a > 2000 character name. However, I'm not sure it would be reasonable to allow names like that:

One other aspect is maintaining compatibilty with the constructs package, where the naming logic should come from.

To sum it up: the only hard requirement is guaranteed uniqueness across the stack, with a few soft requirements attached to this. The current way works reasonably well, and there are a few open issues to make it easier to work with it: see #248, #247, #219

[skorfmann]

Closing as question was answered and the problems discussed are tracked in other issues already.

[github-actions]

I'm going to lock this issue because it has been closed for 30 days. This helps our maintainers find and focus on the active issues. If you've found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.