feature request: inverse targeting / exclude

[shubhambhartiya]

Is there anything that can be done such that db_instance - RDS formed by the terraform files can be saved if we destroy the whole state?

[tburow]

Bump - this would be a very useful core feature....

[sanflores]

Inverse targeting is becoming more and more important in huge terraform plans with lots of modules managed by different teams

[albertoangelici]

Would be very useful for example to exclude Glue Catalog Tables created in Terraform and updated with a cron Glue Crawler, they are never in sync.

[davidgereb]

Would be very useful for example to exclude Glue Catalog Tables created in Terraform and updated with a cron Glue Crawler, they are never in sync.

@albertoangelici maybe you're looking for ignore_changes https://www.terraform.io/docs/configuration/resources.html#ignore_changes

[CYDX-nuna]

/sub

We could really use this right now. I have a number of Redshift instances that I want to be sure we don't touch unless we really mean to, and excluding them would make our lives a lot easier.

[voycey]

Nearly 5 years now! We need this for exactly the same reasons as above - we currently have to script manual backups and Ansible playbooks to back everything up and restore prior to a Terraform destroy - its exhausting.

Its reasons like this that we are considering migrating to AWS CDK, unfortunately I would rather have the grunt of Amazon behind a solution than Hashicorp who won't even answer our support emails on our paid plan 🤷‍♂️

[marcomayer]

+1 we could really use this too

[dturnbu]

+1, I could really use this option that people have been requesting for more than 5 years right now.

I have to work on Terraform code that some people wrote a while back. Unfortunately amongst the multitude of modules that make up this "infrastructure-as-a-labyrinth-of-code" there exists two or three modules that can't be planned or applied without first performing extra steps. Being able to exclude these modules would have saved me an enormous amount of time.

[ghost]

adding my +1

[pshirshov]

Eh, I'm really surprised by the fact that this is still unimplemented. Terraform would be great but its UX is terrible.

[johnlaur]

+1

[yanirj]

+1, just came across the need to keep a VPN gateway configured in the VPC, and I'm unable to destroy everything but that VPN gateway...

[sanflores]

+1, just came across the need to keep a VPN gateway configured in the VPC, and I'm unable to destroy everything but that VPN gateway...

for your case, in my opinion, you should remove that VPN gateway from the terraform >> destroy >> and re import (if needed). terraform state rm aws_vpn_gateway.your_resource_name terraform destroy terraform import aws_vpn_gateway.your_resource_name vgw-xxxxxx

[yanirj]

I am always a bit reluctant to remove and import because sometimes not all information is available via the API for retrieval, only when creating the resource. I'm planning on moving the module usage into a new module and doing "state mv" into that new module, instead...

[jgitlin-p21]

Related PR was closed with comment:

hi! I am cleaning up some older PRs and am going to close this one. Please do chime in on the linked issue if you are still interested - we haven't forgotten this request, but it's going to take some careful design and isn't on our immediate roadmap. Thanks!

Chiming in. I am still interested.

[nwalter82]

Still an issue of needing to exclude things, this comes from trying to write re-usable code but also trying to merge existing installations under terraform management. In my case I have an RDS database that is running in production, I would like to be able to run my terraform script against the production environment while excluding this RDS database for now and then later run it again as part of our replacement/upgrade process for RDS so that we can better schedule just this part of the upgrade.

1st run - terraform apply -exclude aws_rds.mydb 2nd run - terraform apply

The exclude would also have to make sure to exclude anything that the RDS database depends on that are not needed by anything else (kms keys etc).

[ache154]

Echoing everyone else. I was looking for exactly this feature for a large customer few weeks ago.

Instead I had to work around creating a PowerShell script that removes all the resources but keeps some of them. However my solution is not the most efficient way.

I am sure having it natively in Terraform would make the execution more efficient and the usability more friendly.

[wsromek]

Plus one.

[manugarri]

pilling on!

[danpilch]

-exclude=resource would be really useful

[ghostheory]

I would also be helped by this too!!!

[devil47sid]

Yes

[ghost]

I am currently struggling with automation due to not being able to exclude a resource. Scenario:

single terraform configuration creates resources in two separate AWS accounts by overriding provider when calling modules, there is no way to execute it in automation environment where AWS profiles configuration is not supported.

[panda7zip]

-exclude please.

[anuragpulla]

Exclude feature would be really awesome.

[williamdunstanmorris]

hey there - any updates on this feature?

[worldofgeese]

Desperately need this feature

[cdermcarter]

+1 Need this for when people haven't committed their minor or temporary changes to Github yet and I have other production changes to apply out of hours where there are far too many targets to list.

[maxgio92]

Please stop with spam. Please add a reaction to the initial comment and open a PR if you really need this feature now, otherwise wait.

[teodorescuserban]

@maxgio92 , the issue is opened 6 years ago (2015). What do you mean by "wait"?

Just closing the issue with "won't do" seems more reasonable than "wait" at this point :)

[pieterza]

We'd also like this feature!

[OneBadSanta]

@maxgio92 I have added my Thumbs Up reaction to the initial comment. Is there a threshold where action will be taken by someone at Hashicorp once it's reached? If so, what is that number? If not, why did I just add a reaction? Or is the answer for someone to PR it?

There are people here waiting for years who may be under the false presumption that reactions are being taken into account. If they are or are not, we need to know.

[williamdunstanmorris]

Please stop with spam. Please add a reaction to the initial comment and open a PR if you really need this feature now, otherwise wait.

This is a feature request, not a PR request. Users who are commenting on this thread here won't necessarily know the terraform code base, so how would they know how begin a PR? I really don't think this is spam, this is a very nice feature request which may or may not be easy to integrate.

[williamdunstanmorris]

Seems that if you look at some of the previous PRs and issues mentioned issued in this thread from #3366 and alike, this is not a trivial feature to implement.

[jgitlin-p21]

I really don't think this is spam, this is a very nice feature request

But every time you comment just to ask Hasicorp when they're going to build it or say "I need this too" you're actually just emailing over ~1,200~ 605 users who are all just waiting for a useful update. You're not pushing Hasicorp to build it, you're just making me want to unsubscribe from this feature request to stop the useless emails 😢

[thiagolsfortunato]

Any news? 👀

[luisamador]

I'm here for the same. We need a way to exclude resources please :)

[weakcamel]

+1 for the feature!

I'd like to be able to skip a resource when it's temporarily disabled.

In my specific case, I have a list of vsphere_hosts where one of them is currently shut down for maintenance (hardware failure). As it is, I have to work around it with getting a list of all other resources from the same module (and there is a lot of them!) and passing them in with a -target option.

[elouanKeryell-Even]

@weakcamel I think a workaround is to add a custom bool variable (something like enable_vsphere_host_number_1), and set it to false when needed

Here is how it would look:

---

variables.tf

variable "enable_vsphere_host_number_1" {
  default = false
  type = bool
}

---

main.tf

resource "vsphere_host" "myhost" {

count = enable_vsphere_host_number_1 ? 1 : 0

}

• if enable_vsphere_host_number_1 = true, then count = 1 and the resource will be created
• if enable_vsphere_host_number_1 = false, then count = 0 and the resource is skipped

---

Documentation references:

• conditional expressions: https://www.terraform.io/docs/language/expressions/conditionals.html
• the count meta-argument: https://www.terraform.io/docs/language/meta-arguments/count.html

---

Usage:

terraform apply -var='enable_vsphere_host_number_1=false'

---

Disclaimer: this is just an example, it has not been tested, although I have been using something like this in the past and I know the idea works well.

Also, this is just a workaround and is not ideal, I too would like an option like -exclude=...

[teodorescuserban]

@weakcamel I think a workaround could be to implement a bool variable disable_vsphere_host_number_1

at least for me this is the kind of workaround I've been using

Would you be able to provide a bit more details, @elouanKeryell-Even ? Thank you!

[marcelocrocha]

--exclude would really be helpfull. Sometimes, instead of adding 10x --target, you would rather prefer to only exclude one. ;]

[weakcamel]

@weakcamel I think a workaround could be to implement a bool variable disable_vsphere_host_number_1 at least for me this is the kind of workaround I've been using

Would you be able to provide a bit more details, @elouanKeryell-Even ? Thank you!

I second that, @elouanKeryell-Even. I can see how a bool variable could be used to remove/create a host within an array, but I don't see a way to exclude an existing host from being processed (and leave it alone in it's maintenance state). Could you please elaborate?

[elouanKeryell-Even]

@teodorescuserban @weakcamel I have updated my comment with more details: https://github.com/hashicorp/terraform/issues/2253#issuecomment-926442146

[weakcamel]

@elouanKeryell-Even Many thanks for clarification. The example is useful for dealing with an array of resources indeed, when you want to remove or create one in the middle (by flipping the switch on an off). Unfortunately it doesn't solve the problem of ignoring one resource in the middle.

In my particular situation, Terraform provider for vSphere will - in either position of the bool variable - contact vSphere to gather information about the resource (host) and when it can't get that (host is down for maintenance so you can't communicate with it), it will fail.

Repeating -target flag for all the resources except the shut down one allows you to completely ignore the host in maintenance and -exclude would be the complementary inverse flag.

[elouanKeryell-Even]

@weakcamel

I think I get what you mean

In that case, you could temporarily remove the defective resource from terraform state, so that it doesn't try to contact it anymore. Something like:

terraform state rm vsphere_host.myhost

Then, the day the vsphere_host comes back-up, you can re-import it in the terraform state:

terraform import vsphere_host.myhost <vsphere-host-id>

But I admit it becomes quite complicated, and maybe simply using a huge -target= option may be easier at this point

[tburow]

From my perspective, if I have a stack of resources bundled togeather, as an example, a bunch of aws cloud resources, say several lambdas or container micro services. In the event I want to make a change, there’s the scenario that I would like to update something in the stack with out impacting a perticular component or service, because maybe it’s more critical and I don’t want to take an outage.

[weakcamel]

@elouanKeryell-Even I haven't tested this (didn't want to risk breakage) but I suspect that removing a resource from state file from the center of the list would make me fall into the trap outlined here:

https://blog.gruntwork.io/terraform-tips-tricks-loops-if-statements-and-gotchas-f739bbae55f9

aws_iam_user.example[0]: neo
aws_iam_user.example[1]: trinity
aws_iam_user.example[2]: morpheus

When you remove an item from the middle of an array, all the items after it shift back by one, so after running plan with just two bucket names, Terraform’s internal representation will look something like this:

aws_iam_user.example[0]: neo
aws_iam_user.example[1]: morpheus

[teodorescuserban]

@teodorescuserban @weakcamel I have updated my comment with more details: #2253 (comment)

Thank you for clarification, @elouanKeryell-Even. Unfortunately I know about this hack but I can't applied it in my case. :\

[pjaol]

This has been something that I can understand is hard to tackle In cloud infrastructure we're are in a world of cattle not pets, however some services are not ephemeral

• Data Stores
• Identity Providers
• etc..

I'm currently dealing with an IDP that I can't tear down without losing all accounts, there is no access to the underlying data and it's designed that way to ensure that we don't have access to people's passwords, so a good thing. (Migration is not possible in this version of the IDP)

However changing terraform DAG is not an easy feat I think there is a compromise within the existing HCL structure that hopefully isn't too hard

The way I'm was trying to exclude my IDP service is by using

lifecycle {
     prevent_destroy = true
}

This presents me with a nice error that's not helpful

Error: Instance cannot be destroyed

  on cognito.tf line 1:
   1: resource "aws_cognito_user_pool" "cognito-pool" {

Resource aws_cognito_user_pool.cognito-pool has lifecycle.prevent_destroy
set, but the plan calls for this resource to be destroyed. To avoid this error
and continue with the plan, either disable lifecycle.prevent_destroy or reduce
the scope of the plan using the -target flag.

The way I accomplished skipping this was listing all the parameters that would have changed in an ignore_changes array

lifecycle {
      prevent_destroy = true
      ignore_changes = [
        name,
        alias_attributes,
        auto_verified_attributes,
        username_configuration ,
        verification_message_template ,
        schema,
       password_policy ,
       admin_create_user_config,
       account_recovery_setting
      ]
    }

What would be fantastic is if we had a

ignore_changes= ALL

or better yet

ignore_destructive_changes = true

or ultimately introduce a new feature to lifecycle

lifecycle {
 preserve_existing = true #which can then be set via variables and basic logic
}

Would that be feasible ? And should the error message be updated to direct users to look at ignore_changes vs. target + scope

[creganFL]

+1 please add an --exclude= argument