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?

[phinze]

Hi @shubhambhartiya - we have prevent_destroy which provides protection against accidental destruction, but it sounds like perhaps you're asking about "destroy everything but this" feature.

Can you elaborate on the behavior you're looking for?

[shubhambhartiya]

Considering an example. I have a set of tf files which creates vpc, subnets, ASG, sg, instances in various subnets, nat instances and databases (RDS). I want to plan in this way such that when I destroy the plan, I want the RDS to be there (VPC and subnets would be needed), rest all the things would get destroy.

[phinze]

Ah okay I get it now. I think I'd call what you're looking for "inverse targeting".

# Destroy everything except aws_db_instance.foo and its dependencies
terraform plan -destroy -exclude=aws_db_instance.foo

^^ If that looks like what you're asking for I'll edit the title and we can track that feature request with this thread.

[shubhambhartiya]

Yes, that would be a great thing.

[glerchundi]

yes please! :+1:

[josephholsten]

this is related to #4515

[anosulchik]

Just to confirm that it would be nice to have a feature of inverted targeting like as follows:

terraform apply -target-exclude aws_ecs_service.ecs_service

Thanks.

[anagrius]

+1

[analytically]

+1

[beanaroo]

Another use case:

We're importing existing AWS environments. Migrating the DB to the new subnet group is a manual step. It would be nice to provision all the subnet/security/parameter groups before updating the instance (all part of the same module)

[cmacrae]

I'd also love to see this. In the meantime, I'm using a combination of lifecycle to "protect" certain resources, and targeting like so:

terraform plan -destroy $(for r in `terraform state list | fgrep -v resource.address.to.exclude` ; do printf "-target ${r} "; done) -out destroy.plan

Not pretty, but it does the job 🙂

[olenm]

Following what @anosulchik posted:

Just to confirm that it would be nice to have a feature of inverted targeting like as follows:terraform apply -target-exclude aws_ecs_service.ecs_service.

A target and something like a -target-exclude would be great to support regexp or by name-matching similar to consul, such as: terraform apply -target-exclude aws_ecs_service. would match all that start with aws_ecs_service. or if its regexp it can be more explicit which would be ideal

thanks

[ffoysal]

terraform destroy -target-exclude aws_db_instance.my_rds It would be great to have this feature. so that we can destroy everything except rds instance. It will save a significant amount of time for us if we can just destroy everything except rds resource, as rds takes around 30 minutes to create and timeout during destroy

[ColOfAbRiX]

This would be really useful, so I can destroy everything except the resources marked with prevent_destroy. At the moment, because of prevent_destroy, I comment out everything except that code and run apply instead of destroy. Very unintuitive.

[henning]

+1 :)

My current workaround is to taket the outout of "terraform plan list" , grep out all resource I wanna keep, and then create a list of -target parameters from the rest with a shell script.

Another thing that would make it supereasy to destroy everything unless the things you want to keep is to destroy all resources instead of those protected by the "prevent_destroy" flag. Actually, in my opinion the behaviout for that flag is not ideal - if I call destroy, I want to destroy the configured resources, and to me it's somehow logical that the prevent_destroy flag is only for the one resource, not for the whole setup. The way it works now it protects the whole configuration, not the single resource from destruction. And this is the most mentioned reason why people need this here...

[laura-herrera]

Still, it would be very useful to have terraform apply -exclude as sometimes your ECS cluster has changed due to Autoscaling rules and you don't want to change that, but might want to add more resources, etc

[idjaw]

Jumping in to provide a use case I'm trying to meet in which I'm trying to run my tf file but exclude just one resource that calls ansible, which for testing purposes do not want to worry about for the time being. Right now it seems like I have to do several "-target" to include what I want, and that takes a very long time considering how many resources I have in my module.

So, to re-iterate what someone else suggested, something like:

terraform plan -target-exclude="" -target-exclude=""

Ideally, it would be awesome to provide a list:

terraform plan -target-exclude="item1 item2 item3"

[jonvines]

+1

[josephholsten]

Please refrain from commenting on this ticket unless you have something to help complete this ticket.

Speaking of which, could anyone review https://github.com/hashicorp/terraform/pull/3366 and let me know what’s remaining?

[royerhq]

+1

[olenm]

@josephholsten https://github.com/hashicorp/terraform/pull/3366 looks great! looking forward to this, I will test run your code next week on my env and report back

[josefeg]

+1

[JorgeAlmeida]

+1

[jpdoria]

Hello, any updates on this?

[creativeux]

+1

[tdmalone]

@creativeux & others, please refrain from posting +1 comments or other comments that don’t add to the discussion. It increases noise for everyone subscribed to the issue. Use the emoji reactions instead.

[zhao-li]

I found this thread because I was learning Terraform and thought I needed this capability. But I found a workaround that no longer required me to need exclude. Hopefully, it will help others that might be in the same boat as me and help them find their way around Terraform.

If I restructured my configurations, I am able to use data instead of resource, which then allowed me to destroy all of my resources without triggering Terraform to destroy any resource that is managed elsewhere.

So for example, I initially was using:

# terraform-configs/main.tf
resource "aws_ecs_cluster" "my_cluster" {
  cluster_name = "MyCluster"
}

and this told Terraform to manage this cluster and, hence, destroy it when terraform destroy terraform-configs/ is issued.

Then I found that I can move the cluster configuration to another folder so I can still use Terraform to create/destroy/manage it from there, but access it using data instead:

# terraform-configs/transient-stuff/main.tf
data "aws_ecs_cluster" "my_cluster" {
  cluster_name = "MyCluster"
}
# terraform-configs/persistent-stuff/main.tf
resource "aws_ecs_cluster" "my_cluster" {
  cluster_name = "MyCluster"
  ...
}

So now, I am able to issue terraform destroy terraform-configs/transient-stuff/ and not worry about the cluster getting blown away. If I do need to create/destroy/manage the cluster, I can then do terraform destroy terraform-configs/persistent-stuff/.

I'm a newbie at Terraform, so I'm sure there might be an even better way that I am missing. But at least this might avoid needing exclude for now.

Hope that helps :)

[giuliov]

I have an additional scenario to share.

I have trouble with the new configuration of a VM. So I manually disconnected a public IP address using Azure Portal and do not want it to be reconnected when I recreate the machine, but at a later stage when I am happy with my tests and can be sure not to create a security hole.

[ahl]

It would be extremely useful to us to have this; any chance it will be prioritized?

[emmm-dee]

Another +1

Prepping for a migration. I am using a shared module between environment declarations. One component of the module writes public DNS records upon ELB creation. I want this to happen for staging/dev but "not-quite-yet" for production since prod is currently pointed to the current prod env as an A record. New record post-migration is an ALIAS record root module that's being called so I can't just set the current A root domain record to the current value. Sure I could add some conditional logic and add more variables and mess with the module declaration to choose between standard and alias records ugh. What I'm doing is include everything EXCEPT the one dns module that I 'don't quite' want to apply yet in the pre-migration prod environment. This is only temporary but it's hindered workflow for now. Would be so convenient to be able to just exclude that one module instead of include on others that are pending changes.

It just seems logical in software that anywhere you can include something you should also be able to negate it with an exclude in some way.