Backend service resource cannot be used with global network endpoint

[olksdr]

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

• provider.google v3.18.0
• provider.google-beta v3.18.0
• provider.random v2.2.1

Affected Resource(s)

• google_compute_backend_service
• google_compute_region_backend_service

Terraform Configuration Files

## External endpoing config
resource "google_compute_global_network_endpoint_group" "external_proxy" {
  name                  = "external-proxy"
  network_endpoint_type = "INTERNET_FQDN_PORT"
  default_port          = "443"
}

resource "google_compute_global_network_endpoint" "proxy" {
  global_network_endpoint_group = google_compute_global_network_endpoint_group.external_proxy.name
  fqdn                          = "test.example.com"
  port                          = google_compute_global_network_endpoint_group.external_proxy.default_port
}

// NOTE: does not work, since for the global enternal endpoint no health checks are allowed
resource "google_compute_backend_service" "svc" {
  provider                        = google-beta
  name                            = "external-proxy"
  enable_cdn                      = true
  timeout_sec                     = 10
  connection_draining_timeout_sec = 10
 
  custom_request_headers          = ["host: ${google_compute_global_network_endpoint.proxy.fqdn}"]

  backend {
    group = google_compute_global_network_endpoint_group.external_proxy.self_link
  }
}

Errors

without health_checks

Error: Missing required argument

  on main.tf line 211, in resource "google_compute_backend_service" "svc":
 211: resource "google_compute_backend_service" "svc" {

The argument "health_checks" is required, but no definition was found.

with health_checks in code above

Error: Error creating BackendService: googleapi: Error 400: Invalid value for field 'resource.healthChecks': ''. A backend service cannot have a healthcheck with global network endpoint group backends., invalid

  on main.tf line 211, in resource "google_compute_backend_service" "svc":
 211: resource "google_compute_backend_service" "svc" {

Expected Behavior

It should have been possible to create the google_compute_backend_service for google_compute_global_network_endpoint_group without any problem

Actual Behavior

It's not possible to create the google_compute_backend_service since it expects me to set the health_checks but the google_compute_global_network_endpoint_group must be use without any health checks set (according to the docs there is no health check support for this)

Steps to Reproduce

1. configure a google_compute_global_network_endpoint_group with google_compute_global_network_endpoint according to documentation for this provider
2. create the google_compute_backend_service using the documentation for this provider
3. use the above created google_compute_global_network_endpoint_group in the backend service group
4. run terraform apply
5. get the above mentioned errors back

[venkykuberan]

INEG doesn't need health check attribute per doc. @chrisst does provider need to make health_checks as optional if the backend service is for INEG ?

[zshannon]

Is there a known workaround for this bug?

[chrisst]

Firstly I'm going to categorize as a feature since this is new behavior that was implemented in GCP that we don't support yet. Similar to when a new field is added to an API, however this is a new configuration that overloads existing fields.

@venkykuberan this unfortunately can't be something that can be accomplished just by removing the required check for healthcheck. There are other fields in the backend block that are required for other backend types but are not compatible with this new INEG backend type. Most aren't problematic but fields where empty values are valid, such as max_utilization, it's not possible for Terraform to determine if the user has specified a 0, null or nothing in the config so we can't know whether or not to send the field based on just that field's value in config. Basically it's very difficult to know when to omit max_utilization from the API request or when to send an "empty value" which for TypeFloat is 0.0. This will likely require inferring the "type" of backend and stripping the field if it's INEG or adding a new field so that users can explicitly instruct us to omit the field.

ℹ️ There is some more detail about the fields added for NEG in GoogleCloudPlatform/magic-modules#1928

[Sytten]

I will work in this problem since its a blocker for us.

[naseemkullah]

@chrisst @danawillow @ndmckinley

Is there any ongoing work towards resolving this and if not could you suggest a workaround? Thank you 🙏

[naseemkullah]

FWIW, imported global neg backend services include an empty array for health_checks, but cannot subsequently be re-applied, let alone created from scratch as such:

resource "google_compute_backend_service" "on_prem" {
[...]
    health_checks                   = []
[...]

[nat-henderson]

Hello! This is currently in our Goals milestone, which means we agree it will be useful to have done, but it's not currently planned or assigned. We promote things from Goals to Near-Term-Goals and then to a sprint - usually based on number of reactions to the request, as a priority signal.

[naseemkullah]

Thanks for explaining @ndmckinley

[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 👉 [email protected]. Thanks!