Terraform-provider-google: google_compute_subnetwork - 'log_config' does not enable flow logs on a subnet created with an older version of the provider

Created on 29 Nov 2019  ·  7Comments  ·  Source: hashicorp/terraform-provider-google


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.11.14

  • provider.google v2.20.0

Affected Resource(s)

  • google_compute_subnetwork

    Terraform Configuration Files

Initial Terraform code with Flow Logs disable and provider older than 2.19

provider "google" {
  credentials = "${file("/Users/victor.ocanto/.gcp/key.json")}"
  project     = "careful-memory-182717"
  region      = "us-central1"
  version     = "= 2.16.0"
}


resource "google_compute_subnetwork" "subnet-with-logging" {
  name          = "log-test-subnetwork"
  ip_cidr_range = "10.2.0.0/16"
  region        = "us-central1"
  network       = "${google_compute_network.custom-test.self_link}"


}

resource "google_compute_network" "custom-test" {
  name                    = "log-test-network"
  auto_create_subnetworks = false
}

New Terraform code with the 'log_config' argument and upgrade provider 2.20

provider "google" {
  credentials = "${file("/Users/victor.ocanto/.gcp/key.json")}"
  project     = "careful-memory-182717"
  region      = "us-central1"
  version     = "= 2.20.0"
}



resource "google_compute_subnetwork" "subnet-with-logging" {
  name          = "log-test-subnetwork"
  ip_cidr_range = "10.2.0.0/16"
  region        = "us-central1"
  network       = "${google_compute_network.custom-test.self_link}"

  log_config {
    aggregation_interval = "INTERVAL_10_MIN"
    flow_sampling        = 0.5
    metadata             = "INCLUDE_ALL_METADATA"
  }

}

resource "google_compute_network" "custom-test" {
  name                    = "log-test-network"
  auto_create_subnetworks = false
}

Debug Output

Panic Output

Expected Behavior

After upgrade the provider, the presence of 'log_config' block should enable the Flow Logs option.

Actual Behavior

it seems that if a subnet is created using a provider older than 2.19 (with flow logs disable), then upgrade the provider to 2.19 or 2.20 and add the 'log_config' block, Terrafrom does not apply the changes of log_config block.
Every time you do plan/apply, Terraform tries to apply the same change. On apply stage, if you enter 'yes' the output says that changes were applied successfully but actually, they weren't applied, then if you run apply again Terraform says the changes need to be applied.

Steps to Reproduce

  1. create a subnet using provider older than 2.19
  2. change the provider version to 2.19 o later
  3. add 'log_config' block
  4. terraform init
  5. terraform plan
  6. terraform apply
  7. terraform plan

Important Factoids

References

  • #0000
bug

Most helpful comment

Yeah, as mentioned in that issue I would recommend setting
enable_flow_logs while you use version 2.20.1 and then remove it when you upgrade to 3.x where the presence of log_config works correctly.

All 7 comments

Ah, that's no good. The log config enable field defaulted to false in previous versions of the provider and then that value is being respected in 2.20.0.

You can add the enable_flow_logs = true field to your 2.20.0 config and it should enable it

I have the same issue. I am using:

Terraform v0.12.18
provider.google v2.20.1

When using enable_flow_logs I got prompted with:

Warning: "enable_flow_logs": [DEPRECATED] This field is being removed in favor of log_config. If log_config is present, flow logs are enabled.

I tried than to create new subnetworks without using enable_flow_logs and just specifying log_config as follows:

log_config {
            aggregation_interval = "INTERVAL_1_MIN"
            flow_sampling        = 1
            metadata             = "INCLUDE_ALL_METADATA"
        }

This results in the described behaviour of this issue. Applying shows no issues, but another plan says that it wants to enable it again. And an apply does state that it has been changed and activated. But it doesn`t.

@oswalya You are creating a new subnetwork with a log_config and are not seeing it be enabled? Can you provide debug logs for the run that fails to enable logging?

@slevenick
Sry for the misleading description. Creating a subnetwork on the first run works with log_config enabled.
What is not working is a state change afterwards (both ways). If I created the subnet with flow logs enabled and remove now the block from my terraform file another plan shows no diff. Expected behaviour would be: deactivate flow logs.
The other way round it is the same. When I create a subnetwork without flow logs and decide to activate it by adding the log_config block afterwards, a change in the plan / apply is marked but nothing happens. Flow logs are still deactivated. Expected behaviour would be that the flow logs are enabled when the block is defined.

Hope this clearifies it a little bit better.

Yeah, as mentioned in that issue I would recommend setting
enable_flow_logs while you use version 2.20.1 and then remove it when you upgrade to 3.x where the presence of log_config works correctly.

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!

Was this page helpful?
0 / 5 - 0 ratings