bootkube.sh: CEO: properly handle etcd endpoints on retry #2767
Conversation
openshift-ci-robot
added
the
size/XS
|
/lgtm |
|
/test e2e-openstack |
|
test flake /test e2e-openstack |
| @@ -5,7 +5,8 @@ set -euoE pipefail ## -E option will cause functions to inherit trap | |||
|
|
|||
| mkdir --parents /etc/kubernetes/{manifests,bootstrap-configs,bootstrap-manifests} | |||
|
|
|||
| ETCD_ENDPOINTS={{.EtcdCluster}} | |||
| BOOTSTRAP_IP=$(hostname -I | awk '{ print $1 }') | |||
| ETCD_ENDPOINTS=https://"${BOOTSTRAP_IP}":2379 | |||
There was a problem hiding this comment.
Until CEO is ready, can we make sure this value is known empty/broken by default so that the error is clear. And set the correct value in the if else?
There was a problem hiding this comment.
I left ETCD_ENDPOINTS empty. Then added an additional if block[1] to handle retry.
[1] https://github.com/openshift/installer/pull/2767/files#diff-ce82c1d8a44f7dfc41dfc024085ccfeeR118
hexfusion
force-pushed
the
persist_etcd
branch
from
dc57065
to
4a670b0
Compare
openshift-ci-robot
added
size/M
Signed-off-by: Sam Batschelet <sbatsche@redhat.com>
hexfusion
force-pushed
the
persist_etcd
branch
from
4a670b0
to
04ad81e
Compare
|
/approve |
openshift-ci-robot
added
the
approved
|
OOMKilled :) /test govet |
Infra flake |
|
/test e2e-openstack |
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: abhinavdahiya, alaypatel07, hexfusion The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/retest Please review the full test history for this PR and help us cut down flakes. |
2 similar comments
|
/retest Please review the full test history for this PR and help us cut down flakes. |
|
/retest Please review the full test history for this PR and help us cut down flakes. |
This PR resolves an issue where on retry
ETCD_ENDPOINTSwas not properly handled. The result was an invalid list which could lead to installer timeouts.This issue would not yet have affected any clusters as the issue would only be possible if CEO was in a Managed state which to date has not been true.