Closed alanbchristie closed 3 years ago
I used the temporary solution posted danielkucera on 8th August in issue #6986
I am facing same issue I will try the approach mentioned here.
It didnt work T T
Issues go stale after 90d of inactivity.
Mark the issue as fresh by commenting /remove-lifecycle stale
.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen
.
If this issue is safe to close now please do so with /close
.
/lifecycle stale
/remove-lifecycle stale
Issues go stale after 90d of inactivity.
Mark the issue as fresh by commenting /remove-lifecycle stale
.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen
.
If this issue is safe to close now please do so with /close
.
/lifecycle stale
Stale issues rot after 30d of inactivity.
Mark the issue as fresh by commenting /remove-lifecycle rotten
.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen
.
If this issue is safe to close now please do so with /close
.
/lifecycle rotten /remove-lifecycle stale
Rotten issues close after 30d of inactivity.
Reopen the issue by commenting /reopen
.
Mark the issue as fresh by commenting /remove-lifecycle rotten
.
Exclude this issue from closing again by commenting /lifecycle frozen
.
/close
@openshift-bot: Closing this issue.
Description
Behaviour very similar to issue #9575.
Here I'm deploying 3.11 to bare metal and the
openshift_control_plane : Wait for control plane pods to appear
task fails with the same error as #9575: -Version
Ansible version
OpenShift Ansible tag: -
Steps To Reproduce
Expected Results
Control plane pods should appear.
Observed Results
The control-plane pods do not appear.
The output is essentially the same as issue #9575 I lost my output so that issue's error (which is essentially exactly the same) is repeated here...
Additional Information
As discussed in the related issue, the etcd pod is listening using a specific IP address as can be seen by displaying the logs for that pod (i.e. it listens on
134.93.174.200:2379
). But the API service is connection using127.0.0.1:2379
.The work-around, which avoids the installation error is to over-ride the host using
etcd_listen_client_urls
.In my YAML-based inventory I add this...
And it works!
Is it time to ensure that thew etcd pod, out of the box, listens on
0.0.0.0:2379
?