Like 12e711edb2 (data/manifests/bootkube/cvo-overrides: Default to
eus-4.12, 2025-01-15, #9373) and 6ae7f33edf
(data/manifests/bootkube/cvo-overrides: Default to eus-4.14,
2025-04-08, #9643), but for 4.16. I'm a bit late this time, with 4.16
already in EUS since the Maintenance phase ended on 2025-12-27:
$ curl -s 'https://access.redhat.com/product-life-cycles/api/v1/products?name=OpenShift+Container+Platform' | jq -c '.data[].versions[] | select(.name == "4.16").phases[]'
{"name":"General availability","date":"2024-06-27T00:00:00.000Z","date_format":"date","additional_text":""}
{"name":"Full support","date":"2025-01-01T00:00:00.000Z","date_format":"date","additional_text":""}
{"name":"Maintenance support","date":"2025-12-27T00:00:00.000Z","date_format":"date","additional_text":""}
{"name":"Extended update support","date":"2026-06-27T00:00:00.000Z","date_format":"date","additional_text":""}
{"name":"Extended update support Term 2","date":"2027-06-27T00:00:00.000Z","date_format":"date","additional_text":""}
{"name":"Extended update support Term 3","date":"N/A","date_format":"string","additional_text":""}
{"name":"Extended life phase","date":"N/A","date_format":"string"}
Notes: there are other yaml-lint warnings but they've been there for a
long time. This commit only focuses on the errors introduced during 4.19
cycle.
Conflicts:
.golangci.yaml
NOTE(stephenfin): Changes to .golangci.yaml were removed because they
don't apply here.
- lb-default-stable: As a default load balancer is now being assigned when one is not provided this test needs to be updated to reflect that change
- lb-unmanaged: I made changes to how the defaults are set. If the load
balancer is user-managed VIPs will not automatically be assigned
anymore. This change needs to be reflected in this test by adding a
apiVIPs and ingressVIPs value to the install-config
Adds unit tests in platform_test.py to verify OpenStack platform defaults.
Covers cases such as:
- Assigning a default OpenShift-managed load balancer when none is specified
- Handling user-managed load balancers with and without VIPs
- Ensuring correct API and Ingress VIP assignments
-If no load balancer is provided, a default OpenShift load balancer is
now assigned automatically. This ensures proper handling and avoids
misconfigurations.
- Previously, when API and Ingress VIPs were not specified, default values were automatically
generated for user-managed load balancers.This was unintended behavior.
Now, if the user does not explicitly provide API and Ingress VIPs, a fatal error is thrown instead.
This function was doing way more than its name says: it was creating
records in both private and public zones. The argument names were also
not very descriptive and very hard to decipher at a glance.
This change moves the logic out of the function and into the aws
`InfraReady` hook. This not only makes the logic more readable, but it
also paves the way for the use of Classic Load Balancer types.
This is leftover from before CAPA had support for a public LB as the
secondary controlPlane load balancer. We had to configure the AWSCluster
in such a way the primary load balancer would either be `InternetFacing`
if publish was set to "External" or `Internal` otherwise.
Now the primary LB is always `Internal` and the secondary LB only exists
when publish is "External".
Azure is dropping support for properties.storageProfile.source.id on
October 8th, 2025. This update addresses this. Any usage of this field
should be replaced with
properties.storageProfile.source.storageAccountId. In the case of Azure
on Openshift, it is used for compute gallery image versions.
v4.2.0 was chosen since it is the last version of the provider that
supports the same golang version as the installer (v1.21).
The change to use the OpenShift fork of the provider is necessary since
we needed to cherry-pick the commit that fixes this issue.
When there is OpenStack deployment, which doesn't have swift services,
or there are no containers used at all, listing them will fail the
playbook and leave exit code other than 0, which may interrupt CI.
With this commit, errors from listing containers will be ignored, which
will cover both cases.
The hex based dns service is no longer available
and the replacement service does not take PRs
or looks interested in this feature.
If we want this unit test in the future we will need
to think through how to implement this.
Previously, since zones are extracted from map keys, order is not guaranteed.
This can lead to an issue where master CAPI machine manifest is configured
with a different subnet ID than MAPI machine manifest as they are
handled separately.
This commit ensures the zones are sorted by lexical order before
processing CAPI/MAP machine manifests so that zones are distributed in
the same order.
When using BYO subnets, users might define subnets in aws.vpc.subnets
and define the machineCIDRs in the installconfig from those subnets.
Previously, an SG is attached to api lb that only allows ingress to
tcp/22623 (MCS) from the only the first machineCIDR, which blocks master
nodes from reaching MCS on bootstrap node.
This commit adjusts the source for the SG to allow ingress from control
plane nodes via SG reference instead of relying on the machineCIDR field.
this change was made because the OpenShift IPI workflow sometimes
chooses hosts that aren't available right now, due to being powered down
or being on StandBy (DPM measures)
Signed-off-by: Yannick Wahner <12911176+Nabsku@users.noreply.github.com>
** This applies to 4.16 only. The LB Code was migrated to CAPG for all other versions.
** Increase the context timeout for WaitFor operations from 1 minute to 2 minutes. This
was necessary for the Load Balancer (Backend Service) Patch() to have enough time to
complete and verify the operation.
Currently, /etc/resolv.conf on bootstrap node is updated only once.
Because of this, /etc/resolv.conf may be incorrect due to timing
issues. By this change, /etc/resolv.conf is updtaed at all "up",
"dhcp4-update", "dhcp6-update", "dns-change" events.
"dns-change" event is supposed to be enough if it works, but
"dns-change" is a new function[1] of NetworkManager. Other events,
"up", "dhcp4-update" and "dhcp6-update", are kept for environments
where "dns-change" doesn't works.
[1] NetworkManager starting from 1.42.2-12.el9_2 and
1.36.0-17.el8_6 adds a new event `dns-change` which is fired
whenever a change to the DNS configuration happens.
Currently, /etc/resolv.conf on bootstrap node is updated only once.
Because of this, /etc/resolv.conf may be incorrect due to timing
issues. By this change, /etc/resolv.conf is updtaed at all "up",
"dhcp4-update", "dhcp6-update" events.
In a disconnected environment the check for image architecture
generates an error message since the icsp info is not checked,
even though the image create succeeds. This has caused multiple
customer cases to be generated.
