3 ms·

Are there any plans for a conditional way to enable/disable modules that doesn't use "count"? For example: # current method module "foo" { count = var

Are there any plans for a conditional way to enable/disable modules that doesn't use "count"? For example: # current method module "foo" { count = var.enable_foo ? 1 : 0 } # better? module "bar" { enabled = var.enable_bar } Preconditions and postconditions fail the apply run if their condition doesn't validate, so those can't be used. I'd also really like to be able to say in an output block, "this value doesn't have to exist, only display it if its parent module is enabled", again without the "count" attribute.

cube2222 2y ago
The relevant issue[0] is currently the 7th top-voted[1] feature request, so it's definitely high on our radar. Please upvote it as well, if it's important to you! There's a bunch of nontrivial technical complexity though, because of how OpenTofu currently works. [0]: https://github.com/opentofu/opentofu/issues/1306 https://github.com/opentofu/opentofu/issues/1306 [1]: https://github.com/opentofu/opentofu/issues/1496 https://github.com/opentofu/opentofu/issues/1496
paulddraper 2y ago
Use CDKTF. All of these "how can I do X in HCL" just go away.
- lkjfoawerasfw 2y ago
  I do agree CDKTF is an improvement over HCL, but aren't you bothered by being blocked by terraform itself? You have to resort to intrinsics [1]. This is why I dropped CDK for TF in favor of Pulumi, although I do feel Terraform has more maturity and polish but not enough to warrant its limitations. [1]: https://developer.hashicorp.com/terraform/cdktf/concepts/functions https://developer.hashicorp.com/terraform/cdktf/concepts/fun...
  - paulddraper 2y ago
    Once in a while, I forget to use Fn when I should. But I'll take that annoyance anyday over the absolute pain of HCL. I haven't tried Pulumi, I will eventually. (Cloud services have TF providers more often than Pulumi ones. But if Pulumi is easy to extend, maybe doesn't matter.)
    - everforward 2y ago
      I suspect Pulumi is easy to extend because most of the API is basically a state-preserving, idempotent wrapper around existing APIs. When I was messing with it on GCP, their API almost always used the exact same objects the GCP API accepted. I could actually use the GCP docs to create the objects (there are big upsides and downsides to this).

cube2222 2y ago

The relevant issue[0] is currently the 7th top-voted[1] feature request, so it's definitely high on our radar. Please upvote it as well, if it's important to you! There's a bunch of nontrivial technical complexity though, because of how OpenTofu currently works. [0]: https://github.com/opentofu/opentofu/issues/1306 https://github.com/opentofu/opentofu/issues/1306 [1]: https://github.com/opentofu/opentofu/issues/1496 https://github.com/opentofu/opentofu/issues/1496

paulddraper 2y ago

Use CDKTF. All of these "how can I do X in HCL" just go away.

lkjfoawerasfw 2y ago
I do agree CDKTF is an improvement over HCL, but aren't you bothered by being blocked by terraform itself? You have to resort to intrinsics [1]. This is why I dropped CDK for TF in favor of Pulumi, although I do feel Terraform has more maturity and polish but not enough to warrant its limitations. [1]: https://developer.hashicorp.com/terraform/cdktf/concepts/functions https://developer.hashicorp.com/terraform/cdktf/concepts/fun...
- paulddraper 2y ago
  Once in a while, I forget to use Fn when I should. But I'll take that annoyance anyday over the absolute pain of HCL. I haven't tried Pulumi, I will eventually. (Cloud services have TF providers more often than Pulumi ones. But if Pulumi is easy to extend, maybe doesn't matter.)
  - everforward 2y ago
    I suspect Pulumi is easy to extend because most of the API is basically a state-preserving, idempotent wrapper around existing APIs. When I was messing with it on GCP, their API almost always used the exact same objects the GCP API accepted. I could actually use the GCP docs to create the objects (there are big upsides and downsides to this).