Hopefully this is a simple issue that I’ve not understood from the documentation.
I’ve currently got
resource "aws_s3_bucket" "cf_s3_bucket" {
bucket = "my-bucket"
acl = "public-read"
...
}
and I’m in the process of upgrading the configuration so that I can remove the deprecated property/blocks in favour of the new resources. The documentation does say that having both the deprecated elements and the new resources is a bad thing and so removal of the deprecated elements is where I’m trying to end up.
And so, I’ve got this resource
resource "aws_s3_bucket_acl" "cf_s3_bucket" {
bucket = aws_s3_bucket.cf_s3_bucket.id
acl = "public-read"
expected_bucket_owner = var.account_id
}
I’ve run the relevant terraform import
s of the existing ACL config and the plan is clean.
If I now remove the deprecated acl
property,
resource "aws_s3_bucket" "cf_s3_bucket" {
bucket = "my-bucket"
# acl = "public-read"
...
}
the plan now says that this is going back to a private
acl
# module.my-website.aws_s3_bucket.cf_s3_bucket will be updated in-place
~ resource "aws_s3_bucket" "cf_s3_bucket" {
~ acl = "public-read" -> "private"
id = "my-bucket"
...
So I am unsure how to proceed. Leaving both the deprecated property and the new resource in play is a bad move. Removing the deprecated property results in a inappropriate configuration change in the plan.
But, leaving the property with a big comment saying that it must match the new resource does seem to “work”, once the terraform import
is done.