Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Shorthand for optional resources #33750

Closed
ascopes opened this issue Aug 25, 2023 · 2 comments
Closed

Shorthand for optional resources #33750

ascopes opened this issue Aug 25, 2023 · 2 comments
Labels
duplicate issue closed because another issue already tracks this problem enhancement new new issue not yet triaged

Comments

@ascopes
Copy link

ascopes commented Aug 25, 2023

Terraform Version

1.5

Use Cases

Clearer and more concise code that is DRY.

Attempted Solutions

Currently, we use a ternary operator, take this dummy example:

resource "wiremock_server" "stub" {
  count = var.stubs_enabled ? 1 : 0
}

This is okay, but can become more difficult to read. Especially since now everywhere you reference this, you also need to take into account that it is parameterized.

security_group_ids = compact([
  kong_server.security_group_id,
  var.stubs_enabled ? wiremock_server.stub[0].security_group_id : null
])

Over time this can become more and more cumbersome and error prone, especially when refactoring.

Another option is to create reusable modules, but this can often become more and more unmaintainable for simpler cases as it adds complexity due to additional layers of indirection and is more verbose as you have to now also declare a bunch of variables and outputs to communicate with the module.

Proposal

In our codebase, we have lots of places where we want to allow enabling or disabling features based on flags and conditions.

For example, we have a bunch of infrastructure that stubs external integrations that we turn on during platform stress testing to prevent API abuse on the upstream integrations we do not depend on.

To do this, we need the ability to optionally create infrastructure based on conditions, ideally maintaining a clear and readable codebase.

One way that could possibly make this simple to implement is to allow an enabled or count attribute to take a boolean.

resource "thing" "this" {
  enabled = var.enable_thing
  // or
  count   = var.enable_thing
}

This doesn't help with the issue around noise for dereferencing the attributes of optional infrastructure though, unless we were to allow treating 0-or-1 arrays as either existing or not existing when declared this way.

Another way that might be nicer would be to provide a check-like block that could allow nesting multiple resources in bulk.

optional {
  condition = var.stubs_enabled

  locals {
    wiremock_version = "xxx"
  }

  resource "aws_ami" "wiremock" {
    ...
  }

  resource "aws_launch_template" "wiremock" {
    ...
    ami_id = aws_ami.wiremock.id
  }
    
  resource "aws_instance" "wiremock" {
    ...
    launch_template = aws_launch_template.wiremock.id
  }
}

By doing this, all resources within the block can be treated as if they always exist. Outside, referencing them when they do not exist would be an error.

Stuff like outputs could be wrapped in an optional block with the same condition to dereference them when they do not exist, or a try could be used. A ternary could also be used instead.

output "stub_wiremock_instance_id" {
  value = var.stubs_enabled ? aws_instance.wiremock.id : null
}

References

No response

@jbardin
Copy link
Member

jbardin commented Aug 25, 2023

Duplicate of #21953

@jbardin jbardin marked this as a duplicate of #21953 Aug 25, 2023
@jbardin jbardin closed this as completed Aug 25, 2023
@crw crw added new new issue not yet triaged duplicate issue closed because another issue already tracks this problem and removed new new issue not yet triaged labels Aug 25, 2023
Copy link

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 have 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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Dec 11, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
duplicate issue closed because another issue already tracks this problem enhancement new new issue not yet triaged
Projects
None yet
Development

No branches or pull requests

3 participants