hive does not know the rhcos image value and will pass an empty
string for azure machines. In this case, we can leave the image
empty so that it will use the default from MAPI.
Remove the interactive disconnected workflow type. The appliance
embeds registries.conf and CA certificates directly in the system ignition
for bootstrap, eliminating the need for a separate workflow type.
Key changes:
Command-line interface:
- Remove --interactive flag from unconfigured-ignition command
- Remove ContextWrapper and workflow context management
Workflow handling:
- Simplify to always use AgentWorkflowTypeInstall for unconfigured ignition
- Remove AgentWorkflowTypeInstallInteractiveDisconnected constant
- Remove workflow type switching logic in UnconfiguredIgnition
- Remove workflow dependency from UnconfiguredIgnition asset
Mirror configuration:
- Remove RegistriesConf and CaBundle dependencies from UnconfiguredIgnition
- Remove addMirrorData() call (appliance provides this)
- Remove early returns for interactive workflow in mirror assets
Testing:
- Remove interactive-disconnected-workflow test case
- Remove with-mirror-configs test case from unconfigured ignition tests
- Update default dependencies in test helpers
Rationale:
The OVE appliance provides a more robust solution for disconnected
installations by embedding all necessary configuration (registries,
certificates, UI) directly in the appliance image. This approach:
- Eliminates workflow type complexity
- Decouples installer and appliance repositories
- Simplifies the codebase by removing conditional logic
- Aligns with the architecture where MCO manages post-bootstrap config
After first node reboot, the Machine Config Operator manages registry
configuration and trust bundles via IDMS/IDMT resources.
Commit message text generated by: Claude AI <noreply@anthropic.com>
Added cleanup for bootstrap VM FIP in the insatller as part of the
PostDestroyer to streamline FIP creation and deletion to be done by the
installer avoiding orphan FIPs.
Fixes the issue of bootstrap machine logs cannot be collected when installation fails because
the bootstrap VM uses the master security group, which doesn't allow SSH
access from the installation source address. This prevents gathering
diagnostic information needed to troubleshoot failed installations.
- Created dedicated bootstrap security group with SSH access from anywhere
- Tagged with `openshiftRole=bootstrap` for lifecycle management
- Enables SSH access to bootstrap VM for log collection on failure
- Implement PostDestroyer for openstack bootstrap vm
Set the default type EBS volume for machine pools:
- Controlplane, arbiter and worker pool default to gp3 volume.
- Edge pool default to gp2 volume.
The default decision is taken from existing code [0]. This commit just
makes the defaulting earlier.
This also loosens the validation to allow 0 for volume size and iops as
they are int type (i.e. not pointer).
Reference:
[0] fd5a518e49/pkg/asset/machines/worker.go (L102-L117)
GP3 volumes have the ability to configure throughput from 125 MiB/s to
2000 MiB/s. This allows the ability to set this at install time in the
install-config.
https://issues.redhat.com/browse/CORS-4212
Installations using ABI/assisted with 16GiB of RAM on the bootstrap node
were failing with "no space left on device" during bootstrapping. The
live ISO environment uses a tmpfs mounted at /var that is sized at 50%
of available RAM. On systems with 16GiB of RAM, this provides only 8GiB
of tmpfs space.
At the beginning of the bootstrap process, node-image-pull.sh creates an
ostree checkout underneath /var/ostree-container. When this is added to
the regular disk space usage of the later parts of the bootstrap, the
peak tmpfs usage hits around 9.4GiB.
This fix creates a separate 4GiB tmpfs for /var/ostree-container, so
that it is not subject to the limits on the size of /var.
Added a preflight check for the destroy code (AWS) to check if owned
subnets is safe to destroy: subnets are not shared by any other clusters.
An owned subnet should not be shared by other clusters as this is a
misconfiguration, but in practice, it happened [0].
References
[0] https://issues.redhat.com//browse/OCPBUGS-60071
The AWS IAM role and instance profile waiters had a 2 minute timeout
with custom delay options (1-5 seconds). This timeout was insufficient
in CI environment where IAM calls can be throttled.
Increased the timeout to 15 minutes and removed the custom delay
options to use the AWS SDK defaults (min 1s and max 120s).
