DISABLED_HOST_VALIDATIONS for Agent Based Installer

[alexander-bruun]

Is there a way to use DISABLED_HOST_VALIDATIONS environment variable to disable some host validations blocking a Agent Based Installation? Which should be able to go in combination with openshift-install agent create image in order to run on some wonky hardware for homelabbing / testing.

Ultimately i would expect it to embed the environment variable through ignition config in the assisted-service.env file so it's parsed in the Assisted Service Systemd unit on ignition boot. But so far I have not been able to find out how to do this.

Note: I would like to avoid having to use coreos-installer to manipulate the already generated .iso file.

[alexander-bruun]

I found a hack, if I reboot the rendezvous / assisted-service node, put it into single / recovery mode. Then I'm able to set the root password for the ignition environment.

I then edit the file: /var/usrlocal/share/assisted-service/assisted-service.env by adding DISABLED_HOST_VALIDATIONS=validation-id.

The following is a list of all current validationd id's:

        "connected",
        "media-connected",
        "has-inventory",
        "has-min-cpu-cores",
        "has-min-valid-disks",
        "has-min-memory",
        "machine-cidr-defined",
        "has-cpu-cores-for-role",
        "has-memory-for-role",
        "hostname-unique",
        "hostname-valid",
        "belongs-to-machine-cidr",
        "ignition-downloadable",
        "belongs-to-majority-group",
        "valid-platform-network-settings",
        "ntp-synced",
        "time-synced-between-host-and-service",
        "container-images-available",
        "lso-requirements-satisfied",
        "ocs-requirements-satisfied",
        "odf-requirements-satisfied",
        "lvm-requirements-satisfied",
        "mce-requirements-satisfied",
        "mtv-requirements-satisfied",
        "sufficient-installation-disk-speed",
        "cnv-requirements-satisfied",
        "sufficient-network-latency-requirement-for-role",
        "sufficient-packet-loss-requirement-for-role",
        "has-default-route",
        "api-domain-name-resolved-correctly",
        "api-int-domain-name-resolved-correctly",
        "apps-domain-name-resolved-correctly",
        "release-domain-name-resolved-correctly",
        "compatible-with-cluster-platform",
        "dns-wildcard-not-configured",
        "disk-encryption-requirements-satisfied",
        "non-overlapping-subnets",
        "vsphere-disk-uuid-enabled",
        "compatible-agent",
        "no-skip-installation-disk",
        "no-skip-missing-disk",
        "no-ip-collisions-in-network",
        "no-iscsi-nic-belongs-to-machine-cidr",
        "node-feature-discovery-requirements-satisfied",
        "nvidia-gpu-requirements-satisfied",
        "pipelines-requirements-satisfied",
        "servicemesh-requirements-satisfied",
        "serverless-requirements-satisfied",
        "openshift-ai-requirements-satisfied",
        "authorino-requirements-satisfied",
        "mtu-valid"

Then restart the assisted-service unit, this causes previously registered worker / control planes to no longer be registered to the assisted service, so either wait to boot them or then restart them.

If next-step-runner has a older run date than assisted-service in podman ps -a, then that also needs to be restarted.

The cluster installation should now proceed as normally, but I would like to hear if there is a cleaner way to do this.