bumped ocp api to pull in DualReplica being promoted to TechPreview
needed to pin apimachinery to kube 32 since bumping to kube 33 caused a dependency on cluster-api 1.11 which is currently in beta
Signed-off-by: ehila <ehila@redhat.com>
Added platform-agnostic multi-disk support using Ignition configuration embedded in MachineConfigs
Created new disk types: etcd, swap, and user-defined disks
Implemented disk setup validation and feature gates
Added machine config generation for disk provisioning
Review and unit tests were assisted-by: cursor
** Added a common file for all GCP API Clients to be created.
** transferred over all client creation to the common file.
** Transferred over a call for resource manager from v1 to v3 in clusterapi. This ensured that all calls were for the same
version of the api.
** Note: monitoring service needs to be added to the API.
CORS-3916: Update Installconfig to format and accept service endpoints
** Accept service endpoints through the install config
** Service Endpoints should be entered in a format such as
https://compute-exampleendpoint.p.googleapis.com
and the path will be added by the installer to be something like
https://compute-exampleendpoint.p.googleapis.com/compute/v1/.
** The endpoints are formatted to ensure that the version is correct. If the
user would provide a version such as v2 when v1 is required, it would be difficult
for the installer to provide useful errors.
** Send the formatted endpoints to CAPG.
** Format the endpoints to be sent to the GCP Cloud provider (cloud provider config).
** Format the endpoints to be sent to the GCP PD CSI Driver (Infrastructure). This is how most of the
other packages can receive this information as it is passsed through the API Infrastructure.
Note: The GCP PD CSI Driver will ignore the Path of the endpoint.
** Cleaned up the formatting for the endpoints. This includes providing options to format
the enpoints with or without paths. The paths should not be included in the infrastructure
config, because the other packages do not want them (also the infrastructure validation fails).
The changes done here will update the RHCOS 4.20 bootimage metadata.
A notable change is adding the kubevirt artifact for s390x.
This change was generated using:
```
plume cosa2stream --target data/data/coreos/rhcos.json \
--distro rhcos --no-signatures --name rhel-9.6 \
--url https://rhcos.mirror.openshift.com/art/storage/prod/streams \
x86_64=9.6.20250701-0 \
aarch64=9.6.20250701-0 \
s390x=9.6.20250701-0 \
ppc64le=9.6.20250701-0
```
pkg/destroy/gcp/gcp.go:
** In the case where no error exists but the operation is nil when passed into
gcp.go:handleOperation the destroy process would cause a system panic. Now create an
error in this case so that the destroy process will continue and retry if there are more
pending items.
Currently you can only specify a name for an existing Transit Gateway
or Virtual Private Cloud. This can lead to issues since names are not
guaranteed to be unique. So allow a UUID instead of a name.
pkg/destroy/aws:
** Alter the function name from HandleErrorCode to handleErrorCode. The initial thought was that
this function could be used in other areas of the code, but it will remain in destroy for now.
pkg/destroy/aws/shared.go:
** Remove the session import and uses in the file.
** Remove/Change all imports from AWS sdk v1 to v2.
pkg/destroy/aws/errors.go
pkg/destroy/aws/ec2helpers.go
** Remove the Error checking/formatting function from ec2helpers and put the function
in the errors.go file.
** the bulk of the changes are to the ec2helpers file. All of the sdk v1 imports
are removed except for session as this one is engrained too many files currently.
pkg/destroy/aws/aws.go
** Add a client for ELB ELBV2 and IAM to the Cluster Removal Struct. Even though
these changes are mainly to ec2helpers, the other clients were required in for
certain operations.
** The rest of the file updates are alter ARN import to come from aws sdk v2.
updated the topology determination logic to correctly apply the HighlyAvailableArbiter controlPlaneTopology when an arbiter node is included
Signed-off-by: ehila <ehila@redhat.com>
** The child context was set at 1 minute. This should be long enough to determine if an
operation has completed. However, the HIVE team noticed a timeout. The context will not
have a child created, so the original timeout should apply.
This updates validity for generated certs with ShortCertRotation featuregate enabled to 2 hours to make sure slow platforms like Azure or IBMCloud would get a chance to complete installation without a cert rotation in the middle
