Open JacobLey opened 3 years ago
This is quite annoying not to have. Especially if we are trying to follow the best practices recommended by HashiCorp.
It's funny that the company recommends a best practice that it does not support.
We have the same issue too. Need someone from Hashi to take care of this.
+1, my use case is I have shared infra (an AWS VPC, an ECS cluster and some odd bits) that need to be referenced by each module deployed to it (ECS service and supporting assets). Both of these use repositories and workspaces managed using Terragrunt, but I don't want to have to edit the shared workspace's remote_state_consumer_ids
and apply every time I make a new workspace for the service module, nor create a circular dependency in Terragrunt between my workspace modules. If it was its own resource, the service modules could register themselves to the shared workspace's state.
Alternatively, my particular use case could be resolved by allowing remote_state_consumer_ids
to target projects, as opposed to individual workspaces, as all the service modules co-exist in the same project as the shared module. Both solutions allow me to limit scope to only the workspaces I want.
Use-cases
My personal case is I have a
tfe_workspace
for every microservice+environment combination. Workspaces are dependent on each other and across environments. An example section of my.tf
file looks like this:Note in the first case,
qa-foo
andproduction-foo
are dependent onqa-bar
andproduction-bar
respectively. This works as planned.The second case,
qa-bar
has a cross-environment dependency onproduction-bar
. This causes the plan to error. This error is triggered byproduction-bar
being defined in the same top-level block asqa-bar
. Soproduction-bar
cannot referenceqa-bar
in it's own block (even though they are separate resources).(Some terminology clarification) The real world dependency is
qa-bar
depends onproduction-bar
. In terraformproduction-bar
must declare this dependency, so that makesproduction-bar
dependent onqa-bar
in this caseThe actual error is that
production-bar["qa"]
cannot referenceproduction-bar["qa]
, despite the variable not being used in that "execution" of the ternary. (Name changed from real case)Considering that.
tfe_workspace
can logically depend on other resources of the same type, it would be useful to have the option to declare this connection in a separate resource, so terraform can deterministically figure out dependencies.Attempted Solutions
1)
remote_state_consumer_ids
is only necessary whenglobal_remote_state=false
. So I could just open all workspaces up to one-another. For general security/design reasons I would prefer to not do that in name of POLA. 2) Hard-code that edge case. In my case these workspaces already exist, soid
can be known in advance by me and hard-coded. So the line would change to something likeeach.value == "production" ? "abc123" : ""
. This is my current work around. 3) Don't usefor_each
to group resources, and declare each separately. In hindsight this would be the best design for this solution, but I don't have that currently implemented. Migrating to this would mean manually updating each resource pragmatically.Proposal
Create a new resource
tfe_workspace_remote_consumers
. It will take only two parameters ofworkspace_id
andremote_state_consumer_ids
.This ensures any workspace can depend on any other workspace. For backwards compatibility and simplicity, the
tfe_workspace
remote_state_consumer_ids
can continue to act as normal.This pattern of multiple types of resources being able to manipulate the same attributes is used other places like:
aws_sqs_queue
andaws_sqs_queue_policy
https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/sqs_queue https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/sqs_queue_policyaws_security_group
andaws_security_group_rule
https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/security_group https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/security_group_ruleSimilar to those implementations, a note should be included that users should only pick one. Similarly the
tfe_workspace
remote_state_consumer_ids
should expect its value to be possibly set elsewhere if not explicitly defined. Althoughlifecycle { ignore_changes: [remote_state_consumer_ids] }
should do the trick.Request
While this feature would solve my issue, it seems possible there are other solutions around this. If someone could help with those that would be great.
Two thoughts are: 1) Somehow use the
self
value.provisioner
can access its own resource with theself
value. I guess a feature request to terraform core would be granting someself
equivalent to the resource itself. Except I don't really want the resource... I want the group one level higher, with the other resource keyed by environment. 2) Only generate the reference sometimes... My understanding of the actual error is that wheneach.value == "production" ? tfe_workspace.bar["qa"].id : ""
is calculated,tfe_workspace.bar["qa"].id
's value is calculated even though the value is not eventually referenced wheneach.value == "qa"
. If there was some way of not doing that and instead tell terraform "don't calculate this value until absolutely necessary" that could also potentially solve this issue. Again this is probably a feature request to terraform core instead.