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 v0.12.23
google_cloud_run_service
resource "google_cloud_run_service" "default" {
name = "cloudrun-srv"
location = "us-central1"
template {
spec {
containers {
image = "gcr.io/cloudrun/hello:latest"
}
}
}
traffic {
percent = 100
latest_revision = true
}
}
I assumed that it would allow the latest revsion to be used unless told otherwise. Terraform has no control over the container revision and should just verify that the latest one is used.
Terraform errors out:
Error: Error updating Service "locations/europe-north1/namespaces/project-id/services/hello": googleapi: Error 409: Revision named 'hello-00005-raz' with different configuration already exists.
terraform initterraform planterraform applyPush new image to cloud run using Cloud BuildRedo 1-3Remote tfstate is located within GCP Cloud Storage
It uses a Terraform Service account running with Cloud Build CI/CD pipeline. It worked in that past, but since the code has been updated. It starts throwing this error listed above.
A few simular issues, but with different services.
Manually setting resource.google_cloud_run_service.default.template.metadata.name to a value matching the format hello-00005-raz (projectName-revisionNumber-3letterID) makes the update go through, though that's not a viable solution.
The revision name used to auto-update given a new configuration, I am not sure when it stopped doing so.
@hectorj You are correct. In order to autogenerate the revision name, the template.metadata.name must be omitted when Terraform sends the API request. Unfortunately once the revision name gets set in state, there is no way to unset the name to start autogenerating again (it is a computed field, so it will be read and set every time Terraform refreshes).
We are working on a solution to toggle revision name autogeneration via an extra field.
PR has been merged, and will likely be part of the 3.16.0 release scheduled for 4/6/2020.
We've added autogenerate_revision_name as a field. This will toggle the provider to ignore the revision name (template.metadata.name in state) and let it be managed server-side.
If you are receiving Error 409: Revision named '<revision name>' with different configuration already exists. setting autogenerate_revision_name=true will be the way to tell the provider you don't want to manage the revision name (after v3.16.0). Alternatively, you can manage the revision name yourself by changing template.metadata.name to a unique name for each update.
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!
Most helpful comment
PR has been merged, and will likely be part of the
3.16.0release scheduled for 4/6/2020.We've added
autogenerate_revision_nameas a field. This will toggle the provider to ignore the revision name (template.metadata.namein state) and let it be managed server-side.If you are receiving
Error 409: Revision named '<revision name>' with different configuration already exists.settingautogenerate_revision_name=truewill be the way to tell the provider you don't want to manage the revision name (afterv3.16.0). Alternatively, you can manage the revision name yourself by changingtemplate.metadata.nameto a unique name for each update.