This message was deleted.

Can you show where you define the launch template? I'm mainly wondering if you're running up against https://github.com/pulumi/pulumi-eks/issues/633#issuecomment-1000486534

Thanks! I saw that issue, but was struggling to understand why tags would matter? Is there some kind of matching that happens? I'm currently not specifying any tags at all.

My apologies that it's been a while that I've worked in EKS, but I believe the tags are required for the cluster autoscaler for discovery: https://docs.aws.amazon.com/eks/latest/userguide/autoscaling.html#cluster-autoscaler. So I think it is using a matching system in the background to match them to your template

This is just using auto-scaling groups in AWS at the moment though isn't it? I haven't implement K8s CA yet. It's like the AWS ASG isn't using the LaunchTemplate that's on the ManagedNodeGroup?

Right; I think the tags ensure the right launch template is picked up. The person who opened the issue I linked is a Pulumian, though; I can double-check that was the outcome with him (might take a bit as he's in a different timezone).

Yep for sure!

Thank you! We reopened the issue here: https://github.com/pulumi/pulumi-eks/issues/633#issuecomment-1059568165, if you wouldn't mind adding anything else that you've found.

I added my comments there (finally :p). Also did some more investigation. Turns out that the contents of my custom launch template is being copied to the one that's generated and used. However any subsequent updates are not reflected (I guess the copy is a create-time thing). Can confirm that on the EKS console it says the node group is using my launch template, but on the actual ASG / node instances it's using a generated one (with the configuration copied from my custom one). Really weird behavior, not sure if it's Pulumi, or AWS, or TF 🤷

Oh, that's an odd one... Those flags I shared yesterday might help. If you use the

TF_LOG

env var to get the TF output, and instead of piping it, you let it go where it wants (

TF_LOG=DEBUG pulumi up -v=9 --logflow

), you can get the data split out into the provider logs and the engine logs (use

pulumi about

to find out where the logs end up on your machine; it will be the last line in the output:

$ pulumi about
CLI

# ...

Pulumi locates its logs in /var/folders/j_/p8w1p4s900dbnk9pc5gpp2ym0000gn/T/ by default

Then you get output like this in that directory:

$ ls /var/folders/j_/p8w1p4s900dbnk9pc5gpp2ym0000gn/T | grep pulumi
<http://pulumi-language-python.INFO|pulumi-language-python.INFO>
pulumi-language-python.<redacted>.log.INFO.20220330-100938.56922
pulumi-language-python.<redacted>.log.INFO.20220330-100941.56927
<http://pulumi-resource-random.INFO|pulumi-resource-random.INFO>
pulumi-resource-random.<redacted>.log.INFO.20220330-100939.56926
pulumi-resource-random.<redacted>.log.INFO.20220330-100942.56931
<http://pulumi.INFO|pulumi.INFO>
pulumi.<redacted>.log.INFO.20220330-100937.56921

I'm literally working on a blog post about diagnostic data so I had all that handy 😂 But I'm wondering if you ran a debugging run and then explored the

pulumi-resource-aws*

files, I wonder if something there might be helpful as it will split out the Pulumi engine stuff and make it easier to read.

This is actually a different issue (to the one I needed the flags for), but I'll try them anyway 🙂