`terraform plan` lists a resource will be replaced, but `terraform apply` throws an error

[Zman94]

Problem Statement

When running tf plan --out=./tfplan, I see this

...
  # module.apply_aws_sat_location.module.satellite-location.null_resource.satellite_location is tainted, so must be replaced
-/+ resource "null_resource" "satellite_location" {
      ~ id       = "6249488150138523163" -> (known after apply)
        triggers = {
            "API_KEY"        = "NEbVeyabM26IvMkS-Xxw2hrhZqkpVxah7wA8m8aTm_RX"
            "ENDPOINT"       = "cloud.ibm.com"
            "LOCATION"       = "aws-us-east-1-nvirginia-test-z-2"
            "PROVIDER"       = "aws"
            "REGION"         = "us-east"
            "RESOURCE_GROUP" = "Default"
        }
    }

Plan: 1 to add, 0 to change, 1 to destroy.

------------------------------------------------------------------------

When I run tf apply "./tfplan" I get this

Error: Error running command '. .terraform/modules/apply_aws_sat_location.satellite-location/modules/location/../../modules/location/scripts/location.sh': exit status 1. Output: API endpoint: https://cloud.ibm.com
Authenticating...
OK

Targeted account NabooQA (910f83366dbf46a091aa3c69d320438a) <-> 2137386

Targeted resource group Default

Targeted region us-east

                      
API endpoint:      https://cloud.ibm.com   
Region:            us-east   
User:              Zachary.Gleason@ibm.com   
Account:           NabooQA (910f83366dbf46a091aa3c69d320438a) <-> 2137386   
Resource group:    Default   
CF API endpoint:      
Org:                  
Space:                
Location= aws-us-east-1-nvirginia-test-z-2
************* satellite location already exist *****************

Expected

Terraform apply doesn't delete a location that already exists as this will cause issues. For example,

Use case 1:
If we own all clusters under that location it means they will all get deleted prior to deleting the location
Then everything would get rebuilt causing outages on the order of hours

Use case 2:
If we don't own all the clusters in that location and we also have our own clusters we won’t be able to remove the location.

We need the location to not get recreated on subsequent apply calls.

[anilkumarnagaraj]

@Zman94
...
module.apply_aws_sat_location.module.satellite-location.null_resource.satellite_location is tainted, so must be replaced
-/+ resource "null_resource" "satellite_location" {
~ id = "6249488150138523163" -> (known after apply)
triggers = {
"API_KEY" = "NEbVeyabM26IvMkS-Xxw2hrhZqkpVxah7wA8m8aTm_RX"
"ENDPOINT" = "cloud.ibm.com"
"LOCATION" = "aws-us-east-1-nvirginia-test-z-2"
"PROVIDER" = "aws"
"REGION" = "us-east"
"RESOURCE_GROUP" = "Default"
}
}

Plan: 1 to add, 0 to change, 1 to destroy.

Terraform module for satellite uses 'null_resource' to provision the satellite resources.
'null_resource' internally uses the shell scripts for provisioning. so we don't have actual terraform resource support for full life cycle management of satellite resources.
so in your case location is not getting deleted. It's just re-running the terraform module and replacing the tainted module with un-tainted. Satellite location gets delete only if the user calls the command 'terraform destroy' explicitly.

I re-produce this behavior and you can see in the below snapshot that the location is not getting deleted. it's just re-running the module & using location ID as input for location name & processing it (NOT deleting the location).

[Zman94]

I see. Let me report back and see if I can work with that. That might solve our issues

[Zman94]

Just want to add as a comment that this is a possible workaround. We're testing it as an option. However, we expect that this is something that is fixed when there's a native satellite provider. I'll open another issue if we run into a bug.

[Zman94]

After looking through this and putting it in practice, we discovered an issue with Day 2 operations. While this issue is technically closed from this answer, we need to open a new issue in GHE to address changing locations.