[GLBC] Expose GCE backend parameters in Ingress object API

[bowei]

From @itamaro on February 7, 2017 10:9

When using GCE Ingress controller, the GCE Ingress controller (GLBC) provisions GCE backends with a bunch of default parameters.

It would be great if it was possible to tweak the parameters that are currently "untweakable" from the Ingress object API (AKA from my YAML's).

Specific use case: GCE backends are provisioned with a default timeout of 30 seconds, which is not sufficient for some long requests. I'd like to be able to control the timeout per-backend.

Copied from original issue: kubernetes/ingress-nginx#243

[bowei]

From @bprashanth on February 7, 2017 18:31

This will need to be a per Service configuration since currently ingresses share the backend for a given nodeport, so it makes more sense to specify it as an annotation on the Service. Basically it would be nice if the Service author could publish some timeouts for their Service, and any/all loadbalancers fronting the Service will respect these settings.

[bowei]

From @thockin on February 8, 2017 8:34

The reason for it to be an annotation is that we're not ready to add it to every implementation of Services, yet. Maybe never. I would suggest something like service.kubernetes.io/timeout as the annotation key

[bowei]

From @itamaro on February 14, 2017 17:23

I think I understand the reasoning for an annotation, thanks.

Attempting to tackle this, I got this far.

1. Is this the correct direction?
2. Will appreciate a pointer regarding the next step - how exactly to propagate the timeout value extracted from an annotation to the GCE backend.

[sebbov]

It isn't clear for the state of this issue to me:

• Whether this is done (is this or not yet propagated to the GCE backend?)
• What backend parameters are now configurable (and how, see next). Is this just for the gcloud compute backend-services update <backend>'s --timeout parameter? What about the --connection-draining-timeout one? Are there others this addresses or should address?
• In general, where the documentation lives for this. I shouldn't have to peek at the implementation for that.
  I fail to see how this can have been closed out without addressing this.

thanks,
-seb.

[nicksardo]

See issue #28