Bug 1970002 - IPI vsphere installation failing for having the API VIP moved to master before kube-apiserver starts
Summary: IPI vsphere installation failing for having the API VIP moved to master befor...
Keywords:
Status: CLOSED DUPLICATE of bug 1971864
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Networking
Version: 4.7
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
: ---
Assignee: Beth White
QA Contact: Victor Voronkov
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-06-09 15:40 UTC by Christian Passarelli
Modified: 2024-10-01 18:33 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-08-03 17:53:32 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Christian Passarelli 2021-06-09 15:40:35 UTC
Description of problem:
During the installation of IPI cluster on Vsphere the API VIP is moved to a master node that has not any kube-apiserver running, 
and is not automatically moved back to the bootstrap node that is the unique node with a running kube-apiserver at that moment.
The effect is the installation blocked and not able to continue.

Version-Release number of selected component (if applicable):
4.7.12 was used by the customer reporting the issue.

How reproducible:
Not sure but on the customer side happened 3/3 times.

Steps to Reproduce:
1.
2.
3.

Actual results:
The keepalived on one of the master node became MASTER for the API VIP without having kube-apiserver running.

Expected results:
The keepalived shouldn't move the VIP at that stage or should be able to detect the VIP not working on the master and move it back to the bootstrap node.

Additional info:
The workaround found at this moment is to manually restart the master node owning the VIP to force the VIP 
to be assigned back to the bootstrap node and allow the installation to finish.

Comment 6 Red Hat Bugzilla 2023-09-15 01:09:35 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 500 days


Note You need to log in before you can comment on or make changes to this bug.