The terraform taint
command uses different syntax than all of the other commands, which leads to inconvenient scripting, command-line errors, etc.
Specific Examples:
taint syntax:
terraform taint -module mymodule aws_route53_record.myresource.0
other syntax:
terraform plan -target module.mymodule.aws_route53_record.myresource[0]
terraform apply -target module.mymodule.aws_route53_record.myresource[0]
terraform state show module.mymodule.aws_route53_record.myresource[0]
Is there any plan to allow the taint/untaint
command to
target
syntax as other commands (namely, fully qualified names including the module, and bracket-array indicies)Is there any specific reason why they are different?
If not, would you entertain pull requests to add this enhancement?
0.7 - 0.8.5
*core
Just went to report the same, and found out someone has this problem too
$ terraform plan -target openstack_networking_port_v2.ldap_slave_vip -state dev.tfstate -var-file dev.tfvars
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but
will not be persisted to local or remote state storage.
openstack_networking_network_v2.net-backend: Refreshing state... (ID: eb2453ba-bedb-4e4a-b9b6-136e0d696180)
openstack_networking_secgroup_v2.ldap_slave_endpoints: Refreshing state... (ID: f4b47aaa-3140-470b-81a4-0e7d83ad551d)
openstack_networking_port_v2.ldap_slave_vip: Refreshing state... (ID: 4cc21fe9-ecb0-4ac3-9ae0-6d0c16270107)
No changes. Infrastructure is up-to-date. This means that Terraform
could not detect any differences between your configuration and
the real physical resources that exist. As a result, Terraform
doesn't need to do anything.
$ terraform taint openstack_networking_port_v2.ldap_slave_vip -state dev.tfstate -var-file dev.tfvars
The taint command expects exactly one argument.
Usage: terraform taint [options] name
... rest of help ommited
It's even worse
$ terraform state rm openstack_networking_network_v2.net-backend -state dev.tfstate
No state file was found!
State management commands require a state file. Run this command
in a directory where Terraform has been run or use the -state flag
to point the command to a specific state location.
$ ls -l dev.tfstate
-rw-rw-r-- 1 ubuntu ubuntu 292037 Feb 2 21:31 dev.tfstate
Any update on this? It is causing some confusion for our developers.
This is a horrible UX pitfall. Took me way too long to figure that if I get this:
$ terraform show | grep launch
module.foo.goo.aws_launch_configuration.lc
I need to do this:
$ terraform taint -module foo.goo aws_launch_configuration.lc
@yuvadm thanks so much for posting this, saved me a bunch of time.
Adding to this request.
# terraform state list
...
module.viewer.aws_instance.instance[0]
...
# terraform state show 'module.viewer.aws_instance.instance[0]'
id = i-041ff8b
...
# terraform taint 'module.viewer.aws_instance.instance[0]'
Failed to parse resource name: Malformed resource state key: module.viewer.aws_instance.instance[0]
# terraform taint -module=viewer 'aws_instance.instance[0]'
The resource aws_instance.instance[0] couldn't be found in the module root.viewer.
# terraform taint -module=viewer 'aws_instance.instance.0'
The resource aws_instance.instance.0 in the module root.viewer has been marked as tainted!
Why is this a thing?
This is still an issue. I guess it should be terraform state taint ...
to be more consistent with everything else.
This bug has been open for more than a year. What is the barrier to getting it fixed?
Hi all! Sorry for the inconsistency of this command.
The terraform taint
command unfortunately predates what we now call the resource address syntax, which is what you see used in all of these other commands. It is different than the others only because we didn't yet update it... updating it is definitely something we want to do.
There is already PR #12289 open to address this, but unfortunately due to an oversight on my part we missed it for the 0.11 release window. Since it's a breaking change to the usage of this command I've labelled the PR as "breaking-change", which we use to locate PRs that should be merged during the release period for the next major release, which will be 0.12.
There is not yet a fixed release date for 0.12 since we're still early in its development cycle, but it will be released once we've made good progress on the current focus of integrating an improved version of the configuration language parser and interpreter. With that PR now properly labelled we'll make sure it will be merged while we're prepping for the initial 0.12 release.
@apparentlymart Please, consider adding some magic key or an alias for taint
like taint-new
as it is not clear when 0.12
is out.
This will allow you to bring it in in 0.11.x
series I believe.
This one looks like a dup https://github.com/hashicorp/terraform/issues/15447 btw
If you are creating resources using count
, this is how you would taint:
$ terraform taint -module vpc aws_instance.nat.0
(The hint was in https://github.com/hashicorp/terraform/issues/14357)
Definitely doesn't help that terraform state list
gives the output as:
> terraform state list
..
module.vpc.aws_instance.nat[0]
module.vpc.aws_instance.nat[1]
module.vpc.aws_instance.nat[2]
+1 this is a big time waster, especially when it comes to nested modules and arrays as described by @amitsaha .
Hi all,
This is fixed in master
and ready to be included in the v0.12.0 release, so I'm going to close this out. Thanks for reporting this, and for your patience while we got through other prerequisite work to get it fixed.
Thanks also to @huydinhle for the first pass at fixing this. Other refactoring for v0.12.0 meant that the final implementation was unfortunately quite different in the details, but the design discussion on #12289 was invaluable to see how to implement this behavior against the new internal Terraform APIs that v0.12 work has introduced.
Confusion has not become less, at all. I've tried +10 attempts to taint an AWS instance deployed via terraform-aws-modules/ec2-instanceterraform-aws-modules/ec2-instance
to no avail. I ended up destroying the entire stack, which ended up working much faster than trying to guess the syntax for simply tainting an instance...
Technically the issue may have been solved, but the usage confusion still exists to the same extend as before.
@apparentlymart. This documentation need to be updated https://www.terraform.io/docs/commands/taint.html to use the syntax terraform taint -module
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.
Most helpful comment
This is a horrible UX pitfall. Took me way too long to figure that if I get this:
I need to do this: