terraform apply dependency chain

[cappetta]

I'm seeing an issue in v0.12 where specifying a specific instance to create via --target=module.staging-infrastructure.module.secdevops.aws_instance.kali[0] does not create all the networking dependencies needed to access the instance.

I'm not quite sure what is missing but if I find out, I'll update the ticket. I was able to confirm this issue is resolved when performing a generic "terraform apply --auto-approve" which simply create all assets and allows me to confirm connectivity is successful (e.g. no SG misconfigurations).

I suspect a trace-log would help but please confirm.

[jbardin]

Hi @cappetta,

Is it possible to supply a sample configuration showing the resource and its dependencies, as well as the steps used to create the the initial state? Targeting should only make the minimal changes, so it's possible that if there are no direct references between resources, that other changes may not be applied.

[cappetta]

Sure Can - I also created a GIST of 2 plan outputs. This first plan output is the output of the the --target= setup. This second plan output

The terraform manifests are open-source and located here

Let me know if this helps. I've tried adding a few networking dependencies with the --target declarations but its likely I'm missing something. I'll take a closer look when time permits to see if I can pin-point the missing gap.

FWIW - I am working in a clean AWS env and creating everything from scratch and destroying things often.

[cappetta]

Curiosity got the best of me - this is the terraform apply --target command that booted up the instance and allowed external connectivity. I suspect this might relate to the recent apply logic updates...

--target=module.staging-infrastructure.module.secdevops.aws_instance.kali[0] --target=module.staging-infrastructure.module.network.aws_internet_gateway.gw --target=module.staging-infrastructure.module.network.aws_nat_gateway.nat-a --target=module.staging-infrastructure.module.network.aws_route_table.private-a --target=module.staging-infrastructure.module.network.aws_route_table.public-a --target=module.staging-infrastructure.module.network.aws_route_table_association.private-a --target=module.staging-infrastructure.module.network.aws_route_table_association.public-a --target=module.staging-infrastructure.module.secdevops.aws_security_group.kali

[jbardin]

Thanks @cappetta, we'll take a look at this.

It might be good to note though, that the -target option is not meant to be part of the normal workflow, and is intended to work around exceptional circumstances, like fixing mistakes and certain dependency shortcomings. Even if this issue turns out to be result of a bug, frequently using complex sets of -target options like this makes it all too easy to end up in hard to recover situations.

[cappetta]

@jbardin - not sure if the changes in #22098 impact this issue, I was just looking for the work-around and figured I'd post a note to inquire. I'll plan to retest this after I get a github version of the master cloned/built.

[cappetta]

I "think" it might be resolved / fixed. I'm focusing on a bunch of project updates & testing/tracking this w/ cyber range terraform makefile - will update this ticket after I complete that analysis.

[mildwonkey]

I am going to close this issue due to inactivity.

If there is still a question, I recommend the the community forum, where there are far more people available to help. If there is a bug or you would like to make a feature request, please open a new issue and fill out the template.
Thanks!