Add wildcard for tainting/untaining

[blckct]

I think wildcards in taint command could really be useful so I created this proposal to stir up the discussion.
The exact format of wildcards can be decided but this works for now. It supports commands like:
terraform taint aws_instance.*
terraform taint --module=foo "*" (double qoutes are required so bash doesn't expand it)
terraform untaint *test*

Taint and untaint should work the same.

It removes some error messages so it could be considered a breaking change.
Closes #1768
Closes #16651
Conflicts with #12289

[apparentlymart]

Hi @blckct! Thanks for working on this.

This would be in conflict with #12289, which we're planning to address in the next major release for consistency with other commands. At that point, we'd be using the same resource address syntax used elsewhere, which does not support wildcards.

At the very least we'd need to hold on this until after that is done (the code for that PR has already been adapted into the v0.12 development branch), but at that point we'd have some other things to consider.

In particular, we'd need to devise an extension of the resource address syntax that can serve as a sort of resource address pattern, which we would then use in all of the places where a resource address is currently serving as a selector of potentially-many instances rather than of a single instance, such as in the -target argument.

I think though there's a bigger question about whether it's desirable to make it this easy to mass-taint things. Explicit tainting should be very rare when used as intended, so the common request to mass-taint is presumably driven by some higher-level use-case that Terraform currently lacks support for, and so I'd like to first talk about what those use-cases might be and see if mass-tainting really is the best answer, or if there's a more direct/convenient solution to that problem that would be more first-class.

If you'd be willing, I'd like to discuss use-cases some more in #1768 before moving forward here. There are some shared there already, such as tainting all of the instances of a particular resource or all of the instances in a particular module, but our existing target syntax can already deal with both of those. Ideally the sort of use-case I'm looking for is in terms of a business problem (e.g. gradual deployment) rather than specific ways to solve that business problem.

You are of course far from the first person to ask for the ability to taint by wildcard, but so far we've mainly just gathered a collection of upvotes rather than any significant discussion of what problem is being solved and what other solutions could potentially get us there.

Thanks again for working on this!

[blckct]

@apparentlymart Thanks for a quick reply. I knew it conflicts with planned changes though I didn't realize you could already target whole module or all the instances of a resource, in that case the only thing left for me would be tainting the same resource in multiple modules (I had multiple modules to create dev environment for each dev and those sometimes needed the same changes). #1768 is locked so it makes it hard to partake in discussion.

[apparentlymart]

Unfortunately we often have to lock issues because they just degenerate into useless "me too!" comments that create noise for anyone subscribed, but indeed I will unlock that one now since we clearly have some new things to discuss.

[hashicorp-cla]

All committers have signed the CLA.

[frittentheke]

@blckct I was just wondering if no one ever thought of adding wildcard matching support for tainting resources and then ran into your PR. I still think support for this is really helpful i.e. to have terraform recreate a set of machines or similar tasks - and to do so without having to script anything to produce a full list myself.

Could you maybe rebase your PR and look into the failing CI checks?

[blckct]

@frittentheke Well, it's just one of many PRs that's trying to implement the solution. TBH I don't think there's any point in me spending time on this if there are no plans to merge it.

[crw]

Looking at the history of this PR, the linked PR, and the issue, I am guessing this was not merged due to reconsiderations of how the functionality should work. Given that this PR is going on 6 years, I am going to close it now, but please let me know if you believe it should be reconsidered / reopened despite the intervening time. Thanks!

[github-actions]

I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active contributions.
If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.