gce: HTTPS health checks (feature request and implementation details) #2190
Comments
|
@sparkprime @dhilton do you have any opinions? |
|
I'd 👍 an attribute - that way the code base would be more concise plus us consistent with how the AWS ELB provider makes use of an attribute: https://www.terraform.io/docs/providers/aws/r/elb.html |
|
I would try to follow the official API as closely as possible. What if future versions of the two resources diverge more than they do now? If we add our own extra protocol field, then what if GCE adds its own protocol field to one of the resources. I would not worry too much about maintenance of the Terraform code. We can factor out common elements if necessary to avoid duplicating code / work. I looked into doing this for instance <-> instance_template but decided it wouldn't be worth the hassle. It may well be worth the hassle in this case. |
|
By the way, I am very interesting in helping to implement HTTP load balancing support for GCE in Terraform. Now that HTTPs is public, it seems like a great time to do it. |
|
Thanks. Turns out this might be a moot point right now, because the 🐼 |
|
That's ok, it is really the resource that is beta, we can port everything over to the beta version of the API which should be backwards compatible. We would mark the beta resource as beta in the documentation, as I did in my unmerged PR to merge the autoscaler / instance group manager stuff. |
|
Cool - so how do we make this happen? |
|
Ok let's just switch everything to compute/beta, I'll do that now and run the full set of tests. Then it should be just a case of refactoring the HTTP resource and using this to make an HTTPs resource. |
|
Turns out this was not a good idea. Changing the API to compute/beta means that explicit URLs given in the .tf with /v1/ in them will no-longer be valid, which is unnecessarily disruptive. I'll instead add a new API endpoint called betaCompute specifically for making HTTPs resources. |
|
Ok that is there in #2297 |
Currently HTTPS health checks in GCE are part of the GCE beta API and are not supported by terraform. There's a [feature request](hashicorp/terraform#2190) where these possible implementations are discussed: 1. Alternate resource type: google_compute_https_health_check 2. Add a new attribute `protocol` In this commit remove the HTTPS check and use only HTTP on port 8080, for both the `HTTP/8080` and `HTTPS/443` forwarding rules. The drawbacks are: * We don't check the nginx SSL terminator service in the health check. * The insecure API must be open, at least for the LB layer.
Currently HTTPS health checks in GCE are part of the GCE beta API and are not supported by terraform. There's a [feature request](hashicorp/terraform#2190) where these possible implementations are discussed: 1. Alternate resource type: google_compute_https_health_check 2. Add a new attribute `protocol` In this commit remove the HTTPS check and use only HTTP on port 8080, for both the `HTTP/8080` and `HTTPS/443` forwarding rules. The drawbacks are: * We don't check the nginx SSL terminator service in the health check. * The insecure API must be open, at least for the LB layer.
|
@sparkprime I had a crack at this: master...dcarley:f-https_health_check However I ran into some problems, described in these two commits: Any thoughts? |
|
Welp, |
|
I'll try to find out internally what's going on On Tue, Jul 21, 2015, 4:47 PM Dan Carley notifications@github.com wrote:
|
|
Thanks! |
|
The v0.beta API is still there, but not discoverable. That means a new build of the go client libraries didn't pick it up. That is a bug and people are working on it, so it should re-appear soon. |
|
For large values of "soon", apparently v0.beta is back now. Sorry for the chaos :) I recommend reverse-applying to your branch in order to get unblocked again |
|
@lwander is this necessary for usage of https loadbalancer? |
|
Unfortunately I didn't know we had this work open, so it's been reimplemented and merged into master already. |
|
I can't find it -- this is the health check resource, not the proxy |
|
Ah, right - it's not required since the URL Map resource corresponding to an HTTPS proxy can have a Backend Service checked by HTTP health checks, but it would be good to have. I'll add it in. |
|
@sparkprime this has been merged - #3883 |
|
Thanks for the initial work, @dcarley |
|
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. |
ghost
locked and limited conversation to collaborators
We have
google_compute_http_health_checkwhich configures GCEHttpHealthChecksbut nothing forHttpsHealthChecks.It seems that this could be implemented in one of two ways, each of which have a downside:
google_compute_https_health_checkresource which would duplicate all of the code ingoogle_compute_http_health_checkand need to be maintained in parallel.protocolattribute to the existinggoogle_compute_http_health_checkresource which would involve a lot of conditionals or meta-programming to use the right type from the GCE library.Do you have any preferences?
The text was updated successfully, but these errors were encountered: