ported OES 3.2 code to OSE 3.4 PR 573
Full URL's to pull requests are much more helpful than just a number. Since this bug is for 3.3, that pull request is here.
It has been merged and is in v22.214.171.124 or newer.
It is now ready to be tested.
As the comment https://bugzilla.redhat.com/show_bug.cgi?id=1402536#c35 said, the fix was not included in the latest ocp 126.96.36.199 build.
Move the bug back.
Troy: Is this now in OCP? Should this be in modified state?
After looking at the pull request again, I see that it did *not* make it into the images. My apologies.
I am moving this back to MODIFIED, and I will make sure it makes it into the next image builds, which are scheduled for Tues, Feb. 6.
This has been merged into ocp and is in OCP v188.8.131.52 or newer. I have double checked it this time.
Due to the router still have the issue https://bugzilla.redhat.com/show_bug.cgi?id=1408129#c10 in OCP v184.108.40.206
So QE will verified this bug once above router issue is fixed. thanks.
Verified this bug on OCP v220.127.116.11.13 with ipfailover image id(ba970a85afb9)
1) set up multi-node env with 2 nodes
2) make the router is running on each node
3) create ipfailover service with --replicas=1
4) scale up the ipfailover pod
5) Check those two ipfailover pod are working well and the new create ipfailover pod in another node will enter the 'MASTER' status ,the old one will be enter the 'BACKUP' status.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.