terraform-validator fails to validate resources if project id is (known after apply)

[mw-marcingluc]

validator version: gs://terraform-validator/releases/2020-03-05/terraform-validator-linux-amd64

I am attempting to deploy a single project and run a basic validation to see if only a required set of API's are enabled.

TF plan:

.......

  # module.project.module.project.google_project.main will be created
  + resource "google_project" "main" {
      + auto_create_network = false
      + billing_account     = "REDACTED"
      + folder_id           = "REDACTED"
      + id                  = (known after apply)
      + labels              = {
          + "billing_project"    = ""
          + "classification"     = ""
          + "configuration_item" = ""
          + "data_owner"         = ""
          + "organization"       = ""
          + "pau"                = ""
        }
      + name                = "REDACTED"
      + number              = (known after apply)
      + org_id              = (known after apply)
      + project_id          = (known after apply)
      + skip_delete         = (known after apply)

 .....

When running validator: ~/terraform-validator-linux-amd64 validate plan.json --policy-path=policy-library

I encounter the following error:

~/terraform-validator-linux-amd64 validate plan.json --policy-path=policy-library Error: converting tfplan to CAI assets: converting resource google_project: converting asset: project: required field is not set

I am able to successfully get validator to work by specify a random project id available in the org:

~/terraform-validator-linux-amd64 validate plan.json --policy-path=policy-library --project valid-project-id-of-random-project

It looks like validator is failing because the state file does not yet have a valid project_id that it can query against. From poking around,I believe the --ancestry flag is designed to combat this issue but I have not been able to get this to work. Folders themselves are created outside of this main.tf so those are also not available in the state.

$ ~/terraform-validator-linux-amd64 validate plan.json --policy-path=policy-library --ancestry=organization/redactedID/folder/redactedID Error: converting tfplan to CAI assets: converting resource google_project: converting asset: project: required field is not set

$ ~/terraform-validator-linux-amd64 validate plan.json --policy-path=policy-library --ancestry=organization/redactedID/folder/redactedID --offline Error: converting tfplan to CAI assets: converting resource google_project: converting asset: project: required field is not set

[travmcvey]

It looks like this occurs when the project-factory random_project_id is set to true. The project_id is not known until the apply which flags this error. Setting this to false, got around this issue.

[lvaylet]

Exact same issue here with a new project being assigned a random project ID and the same version of terraform-validator for Linux.

# google_project.main will be created
   + resource "google_project" "main" {
       + auto_create_network = true
       + billing_account     = "REDACTED"
       + folder_id           = "REDACTED"
       + id                  = (known after apply)
       + name                = "REDACTED"
       + number              = (known after apply)
       + org_id              = (known after apply)
       + project_id          = (known after apply)
       + skip_delete         = (known after apply)
     }

@travmcvey Would you mind detailing your workaround? I am not sure which flag to set to false, or where to set it.

[mw-marcingluc]

@lvaylet - @travmcvey is referring to https://github.com/terraform-google-modules/terraform-google-project-factory. The workaround is to set the "random_project_id" variable to false here.

I was able to validate the same behavior on my end. Looks like terraform-validator expects the project_id to be known ahead of time. When assigning a project_id by appending a random hash, the project_id is only known after the apply.

[lvaylet]

Thank you @mw-marcingluc. Then I guess I am in a slightly different situation then. I also append a random two-letter string at the end of new projects. However, I use the random provider to do so (not the Project Factory) and I am afraid I cannot simply disable this feature. Are you looking for a similar workaround? Would you happen to have one in mind already?

[travmcvey]

Hey @lvaylet - I think you could resolve this by passing the random ID as a variable, as a work-around. It seems to be an issue when the project-id is not unknown until after the apply. I don't know much more than that. Thank you!

[lvaylet]

Hey @lvaylet - I think you could resolve this by passing the random ID as a variable, as a work-around.

Hey @travmcvey - do you mean I should try defining a Terraform variable like export TF_VAR_random_id=<...> before calling terraform-validator? I am still confused, as this random 2-letter part might not be known until after the apply. Or do you mean I can use any 2-letter variable? In the meantime, I will run some tests locally and analyze the output of terraform plan to check whether the random provider saves anything interesting there. Thank you!

[travmcvey]

Hey @lvaylet - I think you could resolve this by passing the random ID as a variable, as a work-around.

Hey @travmcvey - do you mean I should try defining a Terraform variable like export TF_VAR_random_id=<...> before calling terraform-validator? I am still confused, as this random 2-letter part might not be known until after the apply. Or do you mean I can use any 2-letter variable? In the meantime, I will run some tests locally and analyze the output of terraform plan to check whether the random provider saves anything interesting there. Thank you!

Close! I am assuming you are doing something like this:

resource "random_id" "random_project_id_suffix" {
  byte_length = 2
}

locals {
base_project_id = var.project_name
new_project_id  = format("%s-%s", local.base_project_id, random_id.random_project_id_suffix.hex)
}

resource "google_project" "new_project" {
  name        = var.name
  project_id  = local.new_project_id
}

This is resulting in a new random id, done at apply.

I am suggesting to, get around the validator error, which still needs to be fixed.

Add in some logic for the random generator

variables.tf:

variable "random_generator" {
  type    = bool
  default = true
}

variable "custom_random" {
  type    = number
  default = 00
}

Then in locals.tf modify this:

locals {
base_project_id = var.project_name
new_project_id  = var.random_generator ? format("%s-%s", local.base_project_id, random_id.random_project_id_suffix.hex) : format("%s-%s", local.base_project_id, var.custom_random)
}

Then when running validator you would set TF_VAR_random_generator=false and TF_VAR_custom_random=01 As an example, essentially not changing too much logic (Adding a random number to a project), but getting past this interesting error of terrafrom-validator.

[lvaylet]

You guessed right. Our code is very similar.

Now I see how we can combine the random provider with local variables and conditional expressions to get a predictable "random" suffix that we can feed to terraform-validator to work around the current limitation. Thanks a lot for your time and the comprehensive example. You made my day!

[travmcvey]

You are welcome! Awesome, I am so glad to hear this is sufficient work-around! Let's hope they resolve the underlying issue.

Regards,
Travis McVey

[dooman87]

It seems that this and #132 related.

[marktru]

Internal issue: b/211887519