digitalocean_spaces_bucket_cors_configuration: Updating allowed origins has no effect

[MauriceArikoglu]

Consider the below scenario for an update to digitalocean_spaces_bucket_cors_configuration of a spaces bucket (cdn enabled). From documentation and platform UI, it becomes clear that adding multiple cors origins is possible. Using terraform, the update does not go through, even though the apply states success.

~ resource "digitalocean_spaces_bucket_cors_configuration" "cors" {
        id     = "my-id"
        # (2 unchanged attributes hidden)
      - cors_rule {
          - allowed_headers = [
              - "*",
            ] -> null
          - allowed_methods = [
              - "GET",
              - "HEAD",
            ] -> null
          - allowed_origins = [
              - "https://*.example.com",
            ] -> null
          - expose_headers  = [
              - "*",
            ] -> null
          - max_age_seconds = 300 -> null
        }
      + cors_rule {
          + allowed_headers = [
              + "*",
            ]
          + allowed_methods = [
              + "GET",
              + "HEAD",
            ]
          + allowed_origins = [
              + "https://*.example.com",
              + "sub.another.com",
              + "www.sub.another.com",
            ]
          + expose_headers  = [
              + "*",
            ]
          + max_age_seconds = 300
        }
    }

[danaelhe]

Oh yes, I'm able to reproduce it as well:

  # digitalocean_spaces_bucket_cors_configuration.test will be updated in-place
  ~ resource "digitalocean_spaces_bucket_cors_configuration" "test" {
        id     = "seyedries"
        # (2 unchanged attributes hidden)

      - cors_rule {
          - allowed_headers = [
              - "*",
            ] -> null
          - allowed_methods = [
              - "POST",
              - "PUT",
            ] -> null
          - allowed_origins = [
              - "https://s3-website-test.hashicorp.com",
            ] -> null
          - expose_headers  = [
              - "ETag",
            ] -> null
          - max_age_seconds = 3000 -> null
        }
      + cors_rule {
          + allowed_headers = [
              + "*",
            ]
          + allowed_methods = [
              + "POST",
              + "PUT",
            ]
          + allowed_origins = [
              + "https://s3-website-test.hashicorp.com",
              + "sub.another.com",
            ]
          + expose_headers  = [
              + "ETag",
            ]
          + max_age_seconds = 3000
        }
    }

Will investigate 👍 thanks for bringing this to our attention.

[danaelhe]

Hi there,

We've uncovered the bug on our end. Turns out it's at the API layer. The database team has created a ticket to address it. In the meantime as a workaround, you can create multiple COR rules to support multiple origins:

  cors_rule {
    allowed_headers = ["*"]
    allowed_methods = ["PUT", "POST"]
    allowed_origins = ["https://s3-website-test.hashicorp.com"]
    expose_headers  = ["ETag"]
    max_age_seconds = 3000
  }

  cors_rule {
    allowed_methods = ["GET"]
    allowed_origins = ["*"]
  }

Will keep this issue opened until it is resolved.

[MauriceArikoglu]

Hi @danaelhe thank you.

I have another issue I am unsure to create an issue for, since it only affects terraform on the side.

We have a kubernetes cluster with update policy. Last Monday the update was applied by digitalocean while running terraform apply (from 1.27.6 to 1.27.10). Now, the underlying droplet was destroyed in this process. With it, the resource monitors created by terraform were destroyed by the update. This all happened on digitalocean's side and terraform is unaware of this.

Now we wanted to reapply terraform to push some updates and were greeted by a terraform error that should already be known to your team:

[danaelhe]

Hi @danaelhe thank you.

I have another issue I am unsure to create an issue for, since it only affects terraform on the side.

We have a kubernetes cluster with update policy. Last Monday the update was applied by digitalocean while running terraform apply (from 1.27.6 to 1.27.10). Now, the underlying droplet was destroyed in this process. With it, the resource monitors created by terraform were destroyed by the update. This all happened on digitalocean's side and terraform is unaware of this.

Now we wanted to reapply terraform to push some updates and were greeted by a terraform error that should already be known to your team:

Interesting....could you create a separate github issue so we can track this better?