Add internal load balancer to GCP.#2448
Add internal load balancer to GCP.#2448openshift-merge-robot merged 4 commits intoopenshift:masterfrom
Conversation
a12f357 to
39c6311
Compare
|
/test e2e-gcp |
|
/retest |
|
The master machines have reference to a dropped resource, which is making it fail when updating status of the machine.
|
Adds an internalTCP load balancer with instance groups containing the masters and bootstrap node(which has been removed from the external LB target pool). Points internal DNS to use this load balancer. Due to the restriction in the internal load balancer we can only perform one health check, so no health check is being performed against the mcs. We are assuming that if the api is alive and ready, so is mcs.
The move to internal load balancers means we replace the ign target pool with an instance group. This commit removes the ignition target pool from the machine provider spec.
39c6311 to
f869204
Compare
|
/test e2e-gcp |
|
/approve /cc @jstuever |
|
@patrickdillon: The following test failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: abhinavdahiya, patrickdillon The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
JIRA: CORS-1235
Adds an internalTCP load balancer with instance groups containing the masters and bootstrap node(which has been removed from the external LB target pool). Points internal DNS to use this load balancer. Due to the restriction in the internal load balancer we can only perform one health check, so no health check is being performed against the mcs. We are assuming that if the api is alive and ready, so is mcs.