Support workspace-driven module enablement

[fishpen0]

It has been difficult to transition our terraform over to using workspaces largely due to a lack of workspace support in modules. I would like to decide whether or not to run a given module based on which workspace I am in. For resources, I have been able to utilize count in a hacky way to make this work, but modules do not support this method. It has been time consuming and complex to rewrite literally every module to have an "enabled" option that passes count to every resource inside of it. This is doubly dirty if count is already being utilized by a given resource in the module as the logic starts to stretch over multiple lines and becomes less readable.

I would like to propose simply adding an "enabled" flag to modules as this could be utilized for many purposes and would hopefully be easer to implement as a stopgap until a solution for #953 is found.

[apparentlymart]

Hi @fishpen0,

We are aware of this limitation and are planning to address it. We need to do some other work first in order to change Terraform's internal representations to support the idea of modules that may or may not exist, since currently the module tree is a very static idea.

An "enabled" flag is, unfortunately, not significantly easier to implement than count because it runs into the same assumptions that Terraform currently makes about the module tree.

The longer-term idea here is to support per-workspace variables (stored in the backend) and then allow conditionals based on those variables, so that configuration is not directly coupled to specific workspace names but rather it's handled indirectly by setting a variable to a different value in each workspace.

There is some work currently underway to improve the configuration language which is in this same stream of work of gradually retrofitting Terraform's internals to better support more "dynamic" behavior (varying based on variables and resource results); after the configuration language is in good shape we will move down to the next layer of how Terraform models configuration and state internally, and that will be our opportunity to reshape the internal modelling of resources and modules to handle count in a more robust way that can generalize to modules as well.

[nilo]

Hi @fishpen0,

I had the same problem. I created a python script to help me with this, https://github.com/nilo/tr_env

You tag your resource/module/var/... with EXCLUDE: "env name" that you want to exclude in the terraform command.

Pretty simple take a look! In the future, you can change to the "official" way without much problem. :)

[apparentlymart]

Hi all! Sorry for the long silence here.

Coming back to this issue later with fresh eyes, I think it's largely a combination of other requests we're already tracking in other issues:

• count and for_each for modules #17519: for_each for modules
• Support the count parameter for modules #953: count for modules
• Workspace-specific Automatic Variable Values #12845: Workspace-specific Automatic Variable Values

These three features all together cover the likely solution I was discussing in my previous comment, and all of them are things we plan to move forward with in some way (detailed design still TBD in the case of #12845) when time allows.

I think leaving this issue here is likely to cause it to just get forgotten again, since the other issues cover more specific ideas and are thus easier to find when posting updates, so I'm going go close this one and let the other three cover the different ideas here and we'll post updates there as we have them.

Thanks for sharing these use-cases @fishpen0, and sorry again for the lack of updates here.

[ghost]

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.