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

Terraform taint/untaint syntax inconsistent with 'plan', 'apply', 'state', etc. #11570

Closed
matt-deboer opened this issue Jan 31, 2017 · 17 comments

Comments

@matt-deboer
Copy link
Contributor

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

  • allow consistent target syntax as other commands (namely, fully qualified names including the module, and bracket-array indicies)
  • allow multiple targets to be specified
    ?

Is there any specific reason why they are different?
If not, would you entertain pull requests to add this enhancement?

Terraform Version

0.7 - 0.8.5

Affected Resource(s)

*core

@michalmedvecky
Copy link

michalmedvecky commented Feb 2, 2017

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

@michalmedvecky
Copy link

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

@mtougeron
Copy link
Contributor

Any update on this? It is causing some confusion for our developers.

@yuvadm
Copy link

yuvadm commented May 14, 2017

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

@danhart
Copy link

danhart commented Jun 1, 2017

@yuvadm thanks so much for posting this, saved me a bunch of time.

@Gary-Armstrong
Copy link

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?

@non7top
Copy link

non7top commented Jan 26, 2018

This is still an issue. I guess it should be terraform state taint ... to be more consistent with everything else.

@jeffgage
Copy link

jeffgage commented Feb 2, 2018

This bug has been open for more than a year. What is the barrier to getting it fixed?

@apparentlymart
Copy link
Contributor

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.

@lig
Copy link

lig commented Mar 23, 2018

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

@lig
Copy link

lig commented Mar 23, 2018

This one looks like a dup #15447 btw

@apparentlymart apparentlymart added cli and removed core labels Mar 23, 2018
@amitsaha
Copy link

amitsaha commented Aug 28, 2018

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 #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]

@seanjfellows
Copy link

+1 this is a big time waster, especially when it comes to nested modules and arrays as described by @amitsaha .

@apparentlymart apparentlymart added this to the v0.12.0 milestone Nov 2, 2018
@apparentlymart
Copy link
Contributor

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.

@baccenfutter
Copy link

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.

@karthikns16
Copy link

@apparentlymart. This documentation need to be updated https://www.terraform.io/docs/commands/taint.html to use the syntax terraform taint -module . I tried tainting using the documented procedure and it kept on failing. @amitsaha thank you for the tip.

@ghost
Copy link

ghost commented Jul 25, 2019

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.

@ghost ghost locked and limited conversation to collaborators Jul 25, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests