Python CDKTF debugging - how?

Terraform CDK for Terraform
1

I’m getting started with CDK for TF in Python and just trying to figure out how to access information to aid in building a project I’m working on.

I’m trying something relatively simple, like using a data block to pull information, then trying to print the output, but it seems to just throw out some useless output and I’m not really sure how to get around it.

For example:

sso_instances = DataAwsSsoadminInstances(self, 'sso_instances')

for arn in sso_instances.arns:
          print(arn)

I would expect this to print a list of ARNs returned by the data block, but instead I get:

#{TfToken[TOKEN.4]}

Am I doing something wrong, or does it not support this kind of workflow?

Appreciate any help.

2

You would need to use TerraformOutput for that. With cdktf you have to distinguish synth time and execution time. Your code is synthesized into static HCL-like JSON and then executed, therefore you can not do anything dynamic. If you are interested in the outputs you can expose them through TerraformOutput; If you want to pass them to another resource you can do that and the token you are seeing there is going to be synthesized into the right reference. But you can not do things like mapping over a list or filtering it easily in cdktf yet.

3

Hmm, I thought the main benefit of the CDK was that you can take advantage of the full capability of a programming language to do more complex logic than what Terraform supports, however if none of this information is available until runtime then that kind of defeats the object, no?

I suppose it must be possible to also include boto3 and use those values for logic?

4

The idea behind CDKTF is that you can use the full capabilities of a programming language to specify your infrastructure requirements. Building dynamic capabilities (so things that react to execution time information) is currently not in scope. The reason is that it’s almost impossible to do safely since you can not plan these types of changes and therefore an undetected bug could cause a lot of harm.

5

OK, thanks Daniel. That clears up some misconceptions I had about the tooling. It might be an antipattern, but I think using boto3 to pull data for things that haven’t (and won’t) change will be sufficient for our use case. I can understand how this could be tricky if resources were changing underneath you, but in some use cases it makes things a lot easier.