-
Bug
-
Resolution: Duplicate
-
Critical
-
None
-
4.14, 4.15, 4.16
-
Quality / Stability / Reliability
-
False
-
-
None
-
None
-
No
-
None
-
None
-
Rejected
-
None
-
None
-
None
-
None
-
None
-
None
-
None
-
None
Description of problem:
Background was discussed on the 4th of Jan, at the Cluster Lifecycle arch call https://docs.google.com/document/d/1RAkb9QL8Gg7USFiuZi2RpgTZwi-ieTDCdG4YOOkxWaE/edit#heading=h.r3ocw8ihu56b By 4.17, we need to have understood the impact of the Azure retirement of the default outbound access egress solution on existing clusters. https://azure.microsoft.com/en-us/updates/default-outbound-access-for-vms-in-azure-will-be-retired-updates-and-more-information/ When the removal happens (Q4 2025), we will need 4.14+ clusters to have been updated to make sure that existing nodes do not lose egress, and that new nodes can successfully join the cluster. Installer team have plans to solve the issue for Day 0 via https://issues.redhat.com/browse/CORS-2767 We must make sure that day 2, things continue to work. We must also make sure that we warn customers and give them a year to solve the issue. Hence the deadline for this work is September 2024. To test ahead of time, Azure recommend using private subnets. Creating a public cluster with private subnets should allow us to test the cluster state without outbound access. https://learn.microsoft.com/en-us/azure/virtual-network/ip-services/default-outbound-access#why-is-disabling-default-outbound-access-recommended
Version-Release number of selected component (if applicable):
How reproducible:
Steps to Reproduce:
1.
2.
3.
Actual results:
Expected results:
Additional info: