brikis98 / terraform-up-and-running-code

Code samples for the book "Terraform: Up & Running" by Yevgeniy Brikman
http://www.terraformupandrunning.com/
MIT License
2.92k stars 1.93k forks source link

Destroying a module attempts to destroy read-only remote state too #4

Closed rarkins closed 7 years ago

rarkins commented 7 years ago

I'm following the design approach in "Read-Only State" in Chapter 3, to pull in data from global IAM configuration. The problem I have is that if I try to destroy a configuration group, it also wants to destroy the remote state too. e.g. here is the destroy plan:

- module.server.aws_instance.instance
- module.server.aws_key_pair.keypair
- module.server.aws_route53_health_check.check
- module.server.aws_route53_record.geo
- module.server.aws_route53_record.record
- module.server.aws_security_group.production
- module.server.data.template_file.user_data
- module.server.data.terraform_remote_state.iam

(check out the last line)

In the module's main.tf, the data source is configured like this:

data "terraform_remote_state" "iam" {
  backend = "s3"

  config {
    bucket = "mybucket"
    key    = "global/iam/terraform.tfstate"
    region = "us-east-1"
  }
}

Is there a way to get this to work such that destroy will work?

brikis98 commented 7 years ago

Data sources are read only. Destroying them has no effect on anything, so the actual data in S3 will be unaffected.

rarkins commented 7 years ago

The first/only time I tried it, it failed in its attempt to destroy and hence the comment itself failed, with the typical "terraform does not roll back" warning. I am pretty sure I needed to do some manual intervention before I could continue. Sorry but I don't have the log from that saved though. Maybe I'll try again and risk it

brikis98 commented 7 years ago

I'd have to see what the error says. Again, deleting a data source should have zero effect on the underlying data, so it was probably something different.

rarkins commented 7 years ago

@brikis98 I think you're right about this topic. I destroyed another similar set of configurations and this time it didn't error on the remote data part. The previous time must have been coincidental/unrelated. Thanks.