Allow setting folder_id on google_project to ""

[morgante]

Terraform Version

Terraform v0.11.7
+ provider.external v1.0.0
+ provider.google (unversioned)
+ provider.http v1.0.1

Affected Resource(s)

• google_project

Terraform Configuration Files

locals {
  organization_id = "816421441114"
  folder_id       = ""
}
resource "google_project" "test_project" {
  name       = "My Project"
  project_id = "gcp-fnd-test-project-folder"
  org_id     = "${local.organization_id}"
  folder_id  = "${local.folder_id}"
}

Expected Behavior

Setting folder_id to "" should have the same behavior as leaving it off entirely.

Actual Behavior

The only way to successfully execute this is to leave folder_id off entirely (and create at org level) or leave off org_id (and create at folder level). This has to be hard-coded in the HCL, making variable creation impossible.

The key code is here: https://github.com/terraform-providers/terraform-provider-google/blob/42b07b30e618d3ceabdd6d36f8a13656f137f528/google/resource_google_project.go#L53-L64

Important Factoids

This is critical to being able to dynamically only set the folder ID based on variables or parameters.

[sethvargo]

This is happening because of the use of conflicts_with in the schema, which is doing validation on the presence of keys instead of presence of keys with_values. If we move that validation into the resource-level, this becomes possible at the expense of more code to maintain.

Given the use case (it seems like people would want to use modules and parameterize this as part of a larger "thing"), I think it's a good idea to remove the top-level conflicts_with.

The other downside is that by moving it to resource time, it won't fail during the plan (but will during the apply). Something to consider...

[rosbo]

I opened an issue against Terraform core a few months ago about this.

The answer I got was that HCL2 will introduce a proper concept of unset and null.

For more details, here is the issue I opened:
https://github.com/hashicorp/terraform/issues/16575

Given that we would lose plan-time validation, I suggest we wait until HCL2.

What do you think?

[morgante]

I'm not convinced that we benefit much from plan-time validation, to be honest. In fact, I would suggest we don't need it at all and could instead switch on a single value (whether folder_id is set or not). I think if folder_id is specified, the desired behavior (being in that folder) is clear, even if org_id is also specified.

This is currently causing a fair amount of pain with some key customers.

[sethvargo]

I tend to agree with @morgante that the trade-off leans toward giving customers power of extensibility in the short term

[rosbo]

Alright, you convinced me. I will open a PR soon to fix this.

[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 👉 hashibot-feedback@hashicorp.com. Thanks!