terraform-provider-google: google_logging_project_sink does not work for automatically created sinks

@edwardmedia It happened on the first apply.

The key here is that every Google Cloud project has several resources which always exist. That includes the _Default log sink. These resources can neither be created nor deleted. However, a number of properties on them can be changed, and thus it makes sense to be able to manage them with a tool like Terraform.

The other bug I referenced ( #7587 ) calls these singleton resources;

What is the correct way to manage them with Terraform? Some ways I could imagine:

• Do it like google_logging_project_bucket_config. That is, simply adopt any existing resources if the user asks to ‘create’ them by adding it to the terraform configuration.
• Keep current behavior of google_logging_project_sink . That is, fail on apply when apply attempts to create or delete one of these ‘singleton’ resources. Document that the user needs to run import after adding it to their Terraform configuration, and state rm after removing it from their Terraform configuration. Note that I believe this means that running Terraform to create an entire cloud project from scratch presumably will fail on first apply, then require the user to run ‘import’ of the resource (which was created by but invisible to terraform), then re-run apply to ensure the setup is complete.
• Have Terraform know (via some mechanism) about ‘singleton’ resources and handle them differently. E.g. adopt instead of attempt to create; warn or error on delete; warn or error on a ‘forced replacement’ which would trigger a delete/create. Resources which are not ‘known’ as singleton resources continue to behave as today.

Ideally google_logging_project_bucket_config, google_logging_project_sink, and other Google Cloud resources would have similar behavior.

While I would strongly prefer being able to handle natively in Terraform, I was able to do a workaround using a null_resource to run the required gcloud commands:

resource "null_resource" "default_sink_disable_logging" {

 triggers = {
    project     = google_project.gtm.project_id
  }

  provisioner "local-exec" {
    command     = <<-EOT
    gcloud auth login --cred-file=./credentials.json
    gcloud config set project ${google_project.gtm.project_id}
    gcloud logging sinks update _Default --project=${google_project.gtm.project_id} --log-filter='NOT LOG_ID("cloudaudit.googleapis.com/activity") AND NOT LOG_ID("externalaudit.googleapis.com/activity") AND NOT LOG_ID("cloudaudit.googleapis.com/system_event") AND NOT LOG_ID("externalaudit.googleapis.com/system_event") AND NOT LOG_ID("cloudaudit.googleapis.com/access_transparency") AND NOT LOG_ID("externalaudit.googleapis.com/access_transparency")
    NOT LOG_ID("appengine.googleapis.com/nginx.request") AND NOT LOG_ID("appengine.googleapis.com/request_log")'
    EOT
  }
}

Hi @matthewblain or @estliberitas, are there any updates on this?

Starting in Terraform 1.5 you can now define imports as part of the Terraform configuration, so it should be possible to manage the default sinks with something akin to the below (not tested):

It’s worth noting the limitations with the import statement having tried doing this myself:

1. You cannot use variables inside of the statement
2. import statements can only live in the root module

Hi, is there any update on this issue?

Starting in Terraform 1.5 you can now define imports as part of the Terraform configuration, so it should be possible to manage the default sinks with something akin to the below (not tested):

import {
  to = google_logging_project_sink.default
  id = "projects/${var.project}/sinks/_Default"
}

resource "google_logging_project_sink" "default" {
  name = "_Default"
  project = var.project
  destination = "logging.googleapis.com/projects/${var.project}/locations/global/buckets/_Default"
  filter = "NOT LOG_ID(\"cloudaudit.googleapis.com/activity\") AND NOT LOG_ID(\"externalaudit.googleapis.com/activity\") AND NOT LOG_ID(\"cloudaudit.googleapis.com/system_event\") AND NOT LOG_ID(\"externalaudit.googleapis.com/system_event\") AND NOT LOG_ID(\"cloudaudit.googleapis.com/access_transparency\") AND NOT LOG_ID(\"externalaudit.googleapis.com/access_transparency\")"

  unique_writer_identity = true
}

For anyone else with this issue: You can change your Organization default to disable the _Default sink on new projects. Then you can use Terraform to create/manage a different sink, and pretend the _Default one doesn’t exist. Note: this will not update your existing projects.

I’m sure there are many use-cases that this will not be appropriate for, but it’s an acceptable workaround for me (far better than crashing-out, then importing, then retrying).