No validation for google_compute_network resource name

[aucampia]

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 -v
Terraform v0.14.2
+ provider registry.terraform.io/hashicorp/azuread v1.1.1
+ provider registry.terraform.io/hashicorp/azurerm v2.41.0
+ provider registry.terraform.io/hashicorp/google v3.66.1
+ provider registry.terraform.io/hashicorp/tfe v0.23.0
+ provider registry.terraform.io/microsoft/azuredevops v0.1.1

Your version of Terraform is out of date! The latest version
is 0.15.3. You can update by downloading from https://www.terraform.io/downloads.html

Affected Resource(s)

• google_compute_network

Terraform Configuration Files

resource "google_compute_network" "db_main" {
  name = "db_main"
}

Debug Output

╷
│ Error: Error creating Network: googleapi: Error 400: Invalid value for field 'resource.name': 'db_main'. Must be a match of regex '(?:[a-z](?:[-a-z0-9]{0,61}[a-z0-9])?)', invalid
│ 
│   with google_compute_network.db_main,
│   on database.tf line 1, in resource "google_compute_network" "db_main":
│    1: resource "google_compute_network" "db_main" {
│ 
╵

Panic Output

Expected Behavior

I expect my terraform source to fail validation or planning, before applying.

Actual Behavior

Validation and planning passes, but applying fails.

Steps to Reproduce

1. terraform validate
2. terraform pan

Important Factoids

• AFAIU this is passing validation and planning failing because there is no validation function (ValidateFunc) here: https://github.com/hashicorp/terraform-provider-google/blob/master/google/resource_compute_network.go#L58
• Similar request for validation is rejected: #3420
• Another related request: #9086

References

• #9086
• #3420
• https://discuss.hashicorp.com/t/validate-gcp-resource-names/24206

[upodroid]

@rileykarson Dupe of #3580 and #8347

Futher details are in #8347 but plan time validation will never be perfect and end users are expected/required to be reading API documentation to supply valid values to Terraform.

In short Terraform plan-time validation is broken/buggy as explained below:

• Google doesn't have an API for testing values. Failures are detected after a POST API Call is made and this done during the apply step.
• Some resources don't allow certain values to be specified.

# There are 2 illegal configs in this VMs. Both are noted in the Google Docs
resource "google_compute_instance" "default" {
  name         = "test"
  machine_type = "e2-medium"
  zone         = "us-central1-a"

  tags = ["foo", "bar"]

  boot_disk {
    initialize_params {
      image = "debian-cloud/debian-10"
    }
  }

  network_interface {
    network = "default"
  }

  scratch_disk {
    interface = "NVME"
  }

  scheduling {
    on_host_maintenance = "TERMINATE"
  }
}

• Some configurations are illegal because of values configured in a resource that it depends on.

# There are 3 illegal configs here. They are documented in the API docs.
resource "google_compute_network" "main" {
  name = "main"
}
resource "google_compute_subnetwork" "two" {
  name          = "two-bar"
  ip_cidr_range = "10.2.0.0/16"
  region        = "us-central1"
  network       = google_compute_network.main.id
}

resource "google_compute_subnetwork" "one" {
  name          = "foo-bar"
  ip_cidr_range = "10.0.0.0/14"
  region        = "us-central3"
  network       = google_compute_network.main.id
}

• IAM Prerequisites for certain resources and IAM permissions of identity running terraform.
• Field values supported by Google change over time. It is double work for the maintainers as the initial validation logic needs to be amended or removed in the future. It also breaks provider versions when the APIs change.
• Validation coverage varies across resources. Some resources have minimal field validations while the older ones have more validation.

Therefore, I advise you not to rely on plan time validation and leverage the API documentation for correct set of values. It will get easier with experience.

[aucampia]

@upodroid Will you be open to PRs that add schema validation for google_compute_network.name and other fields? The alternative is to implement this stuff in tflint I guess.

[upodroid]

yeah, you can submit a patch that validates that field

[rileykarson]

We validate names for many resources, particularly in GCE. They're a well-known format, and you can likely just reuse the regex from another GCE resource. See https://github.com/GoogleCloudPlatform/magic-modules/blob/a4f009f238cc42580678353535895ebe33a04692/mmv1/products/compute/terraform.yaml#L59-L61 for an example (that one targets address).

3580 / 8347 are generic enough to not really be useful issues, honestly. Validating everything is obviously infeasible, especially as API restrictions drift over time- names are a counterexample, which have fixed validation rules in all but one or two cases. As a broad statement targeted validations make sense as they can save time for users but are generally low-ish priority for the provider team because they're easy for users to work around vs. unsupported fields and provider bugs which are generally hard/impossible to work around.

[melinath]

b/237106880

[prateek2408]

@melinath - Can you assign this one to me please.

[SarahFrench]

Validation was added to google_compute_network in https://github.com/GoogleCloudPlatform/magic-modules/pull/6348, marking this issue as closed

[github-actions[bot]]

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 have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.