Bug 2012780 - The port 50936 used by haproxy is occupied by kube-apiserver
Summary: The port 50936 used by haproxy is occupied by kube-apiserver
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Networking
Version: 4.9
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: 4.10.0
Assignee: Ben Nemec
QA Contact: Victor Voronkov
Depends On:
Blocks: 2043650
TreeView+ depends on / blocked
Reported: 2021-10-11 09:53 UTC by jima
Modified: 2022-04-28 16:28 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Cause: HAProxy configured to listen on a port that may be dynamically allocated to another process Consequence: HAProxy or the other process fail Fix: Move HAProxy port out of the dynamic allocation range Result: No more port conflicts
Clone Of:
Last Closed: 2022-03-10 16:18:42 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Github openshift baremetal-runtimecfg pull 155 0 None Merged Bug 2012780: Avoid dynamically allocated port range for haproxy 2022-01-21 17:13:05 UTC
Github openshift machine-config-operator pull 2797 0 None Merged Bug 2012780: Avoid dynamically allocated port range for haproxy 2022-01-21 17:13:06 UTC
Red Hat Product Errata RHSA-2022:0056 0 None None None 2022-03-10 16:19:10 UTC

Comment 12 Lalatendu Mohanty 2022-01-21 16:41:11 UTC
We're asking the following questions to evaluate the impact of this bug. Specially after seeing https://bugzilla.redhat.com/show_bug.cgi?id=2012780#c11.  The expectation is that the assignee answers these questions.

Who is impacted? If we have to block upgrade edges based on this issue, which edges would need blocking?

    example: Customers upgrading from 4.y.Z to 4.y+1.z running on GCP with thousands of namespaces, approximately 5% of the subscribed fleet
    example: All customers upgrading from 4.y.z to 4.y+1.z fail approximately 10% of the time

What is the impact? Is it serious enough to warrant blocking edges?

    example: Up to 2 minute disruption in edge routing
    example: Up to 90 seconds of API downtime
    example: etcd loses quorum and you have to restore from backup

How involved is remediation (even moderately serious impacts might be acceptable if they are easy to mitigate)?

    example: Issue resolves itself after five minutes
    example: Admin uses oc to fix things
    example: Admin must SSH to hosts, restore from backups, or other non standard admin activities

Is this a regression (if all previous versions were also vulnerable, updating to the new, vulnerable version does not increase exposure)?

    example: No, it has always been like this we just never noticed
    example: Yes, from 4.y.z to 4.y+1.z Or 4.y.z to 4.y.z+1

Comment 16 errata-xmlrpc 2022-03-10 16:18:42 UTC
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 (Moderate: OpenShift Container Platform 4.10.3 security update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


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