Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

versioning enabled = false leads to 'delete markers' #12354

Closed
ghost opened this issue Mar 11, 2020 · 5 comments
Closed

versioning enabled = false leads to 'delete markers' #12354

ghost opened this issue Mar 11, 2020 · 5 comments
Labels
bug Addresses a defect in current functionality. service/s3 Issues and PRs that pertain to the s3 service.

Comments

@ghost
Copy link

ghost commented Mar 11, 2020

This issue was originally opened by @henrikb123 as hashicorp/terraform#24350. It was migrated here as a result of the provider split. The original body of the issue is below.


Terraform Version

v0.12.21

Terraform Configuration Files

resource "aws_s3_bucket" "bucket" {
  bucket = var.bucket_name
  acl    = "private"

  tags   = {
    Name        = var.bucket_name
  }

  cors_rule {
    allowed_headers = ["*"]
    allowed_methods = ["GET"]
    allowed_origins = ["*"]
    expose_headers  = ["ETag"]
  }

  versioning {
    enabled = var.use_versioning
  }

}

Debug Output

Crash Output

Expected Behavior

When use_versioning is set to false I expect the bucket to be created without versioning and with versioning never being enabled on the bucket.

Actual Behavior

From observation it seems like Terraform is first creating the bucket with versioning enabled, then afterwards disabling versioning. This leads to a different behavior compared to expected: all deleted objects are not fully deleted but leave behind 'delete markers', making it hard to e.g. programatically delete empty the bucket (e.g. only bucket owner can remove delete markers).

Steps to Reproduce

  1. terraform init
  2. terraform apply
  3. aws s3 cp foo.txt s3://bucket_name/foo.txt
  4. aws s3 rm s3://bucket_name/foo.txt
  5. terraform destroy

Step 5 will fail complaining of bucket not being empty.

Additional Context

References

@ghost ghost added the service/s3 Issues and PRs that pertain to the s3 service. label Mar 11, 2020
@github-actions github-actions bot added the needs-triage Waiting for first response or review from a maintainer. label Mar 11, 2020
@minamijoyo
Copy link
Contributor

minamijoyo commented Jan 13, 2021

I found enabled = false doesn't have the same meaning as undefined. It means Suspended . Unfortunately, it seems that there is no way to remove the existing bucket versioning configuration if set once.
https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutBucketVersioning.html

The current implementation implicitly set the versioning configuration to Suspended if versioning block changes.
https://github.com/hashicorp/terraform-provider-aws/blob/v3.23.0/aws/resource_aws_s3_bucket.go#L1770-L1808

It causes a problem when writing a generic module for aws_s3_bucket. My workaround is as follows:

s3/aws_s3_bucket.tf

variable "bucket" {
  type = string
}

variable "versioning" {
  type = bool
}

resource "aws_s3_bucket" "test" {
  bucket = var.bucket
  acl    = "private"

  dynamic "versioning" {
    for_each = try([coalesce(var.versioning)], [])
    content {
      enabled = versioning.value
    }
  }
}

main.tf

module "test" {
  source = "./s3"
  bucket = "foo-versioning-test1"

  versioning = null
}

However, I think it doesn't make sense setting Suspended with a new bucket.
In more general, it would be great if we could ignore changing versioning.enabled from null to false.

@grimm26
Copy link
Contributor

grimm26 commented Oct 5, 2021

The provider should make a call of GetBucketVersioning if the config has versioning { enabled = false}. If the bucket does not have versioning enabled or suspended, do not make a PutBucketVersioning call at all.

@justinretzolk justinretzolk added bug Addresses a defect in current functionality. and removed needs-triage Waiting for first response or review from a maintainer. labels Oct 12, 2021
@minamijoyo
Copy link
Contributor

FYI: I found this issue had been already fixed in #22221 in v3.70.0

@anGie44
Copy link
Contributor

anGie44 commented Apr 12, 2022

Closing this as suggested the fix is available in provider versions as early as v3.70.0.

@anGie44 anGie44 closed this as completed Apr 12, 2022
@github-actions
Copy link

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 12, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Addresses a defect in current functionality. service/s3 Issues and PRs that pertain to the s3 service.
Projects
None yet
Development

No branches or pull requests

4 participants