Cloud run memory does not reset to default

[AlistairB]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request.
• Please do not leave +1 or me too comments, they generate extra noise for issue followers and do not help prioritize the request.
• If you are interested in working on this issue or have submitted a pull request, please leave a comment.
• If an issue is assigned to the modular-magician user, it is either in the process of being autogenerated, or is planned to be autogenerated soon. If an issue is assigned to a user, that user is claiming responsibility for the issue. If an issue is assigned to hashibot, a community member has claimed the issue already.

Terraform Version

Terraform v0.14.6
+ provider registry.terraform.io/hashicorp/google v3.56.0

Affected Resource(s)

• google_cloud_run_service

Terraform Configuration Files

First apply

resource "google_cloud_run_service" "default" {
  name     = "cloudrun-srv"
  location = "us-central1"

  template {
    spec {
      containers {
        image = "us-docker.pkg.dev/cloudrun/container/hello"
        resources {
          limits = {
            memory = "512Mi"
          }
        }
      }
    }
  }

  traffic {
    percent         = 100
    latest_revision = true
  }
}

Then apply

resource "google_cloud_run_service" "default" {
  name     = "cloudrun-srv"
  location = "us-central1"

  template {
    spec {
      containers {
        image = "us-docker.pkg.dev/cloudrun/container/hello"
        # resources {
        #   limits = {
        #     memory = "512Mi"
        #   }
        # }
      }
    }
  }

  traffic {
    percent         = 100
    latest_revision = true
  }
}

Debug Output

First run setting memory (and new docker image):

~ spec {
      # (3 unchanged attributes hidden)
    ~ containers {
        ~ image   = "gcr.io/my-project-id/my-app-name:5487eba1595a2a8536a8e1677b2ede3e8d30165e" -> "gcr.io/my-project-id/my-app-name:939eb50df1bfe6799dfbcf99a0861f89f9ad9861"      
          # (2 unchanged attributes hidden)
        ~ resources {
            ~ limits   = {
                - "cpu"    = "1000m" -> null
                ~ "memory" = "256Mi" -> "512Mi"
              }
              # (1 unchanged attribute hidden)
          }
          # (10 unchanged blocks hidden)
      }
  }

Second run resetting back to default:

~ spec {
      # (3 unchanged attributes hidden)
    ~ containers {
      ~ image   = "gcr.io/my-project-id/my-app-name:3ab08c4a422bbd95610ae3133d8d0afc1c4334b6" -> "gcr.io/my-project-id/my-app-name:5487eba1595a2a8536a8e1677b2ede3e8d30165e"
          # (2 unchanged attributes hidden)
          # (11 unchanged blocks hidden)
      }
  }

Panic Output

Expected Behavior

The cloud run service should go back to the default memory limit of 256MB.

Actual Behavior

The cloud run service remained on the memory limit of 512MB. In the YAML looking via the google console you can still see:

resources:
  limits:
    cpu: 1000m
    memory: 512Mi

Steps to Reproduce

1. terraform apply setting cloud run memory to non default
2. terraform apply again, removing the configured memory setting.

Important Factoids

References

[venkykuberan]

It's a computed field, if it's not given in the config provider sets the state with the value returned by API (and its considered user don't want to manage the field) during the Create call.

In your apply 2 (update), you removed the field from the config and tf/provider don't see any change at this point. Provider can't differentiate between an unmanaged field and user removed that field in the config post Create. So no Update call is made to the API.

By explicitly changing the limit.memory=256Mi (default) would make the provider to call the API and update the settings. Hope that helps

[AlistairB]

I guess it depends on the responsibilities of the google terraform provider. My assumption is that the same TF config = the same provisioned cloud components. (To me this is the selling point of config as code, as you don't need to worry about the state of the infrastructure to set it to the desired end state).

This is not true with the cloud run memory example in that if you went straight to step 2 config, you get a different result than going step 1 then step 2, when the final config is the same. Perhaps there is precedent in other components? I would assume that removing settings from TF config would reset them back to the default settings.

[slevenick]

I guess it depends on the responsibilities of the google terraform provider. My assumption is that the same TF config = the same provisioned cloud components. (To me this is the selling point of config as code, as you don't need to worry about the state of the infrastructure to set it to the desired end state).

This is not true with the cloud run memory example in that if you went straight to step 2 config, you get a different result than going step 1 then step 2, when the final config is the same. Perhaps there is precedent in other components? I would assume that removing settings from TF config would reset them back to the default settings.

I would argue that a TF config without a certain field in it means that you don't care what that value is. In most resources this means that the value takes the default value either set in the provider or by the API, but if the value has been changed from that default it will keep its current value as in your example.

From our side this is a necessity for fields that are marked as Computed, as the Terraform provider does not have extensive
knowledge of all of the API-level defaults and what value to reset a field (or nested object) to in the case that you unset it.

In the case of cloud run resource limits, it looks like this is marked as Optional and Computed because there are default values set by the API for both memory and CPU limits. Without being marked Computed this field would show a diff unless you specified the same default values in your config as the API sets.

So, the possible solution for this would be removing the Computed flag on that field, but that would mean users would have to specify the default values listed in the API to prevent seeing a diff on first apply, or require users to set this field on every config to ensure they know what defaults they are setting. I don't think either of these are good options.

The other possibility is for you to explicitly specify in your config that there should be no limits: limits = {} or that you want the default limits, which in my case would look like:

limits = {
  "cpu"    = "1000m"
  "memory" = "256Mi"
}

or similar. Closing this bug as we do not want to support resetting to default when the block is removed in this case.

[AlistairB]

Ok thanks for the response.

[ghost]

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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks!