Make it work with OKD

[fabiand]

The docs should contain a hint of how AI can be used to deploy OKD instead of OCP

[eranco74]

That is correct, but the issue is relevant for assisted-service.
This repo and the docs in it deals with the installer running on the live-iso.
The assisted-service holds the full deployment and docs of the assisted-installer service.
Moving the issue there

[mmartinv]

I tried it my self and I faced the following problems:

• The boot ISO is not correctly generated because the grub file has different paths in RHCOS and FedoraCOS.
• The next_step_runner fails to run the inventory command because running podman within podman does not seem to work out of the box in FedoraCOS and the volume '/run/udev' does not exist within the next_step_runner container.
• Supporting the CNV/Kubevirt-hyperconverged would need some code changes I believe.
• Currently OCS/Rook is not supported in OKD, there's no operator published in operatorhub and there's not documented way on how to install it.

[romfreiman]

The main issue with OKD that the live iso flow wont work - since fedora missing some packages, it actually uses another disk to flush new rootfs. So it will basically will require some redesign. @vrutkovs can provide more details here.

Another gap is that our auth is based on PS - and this will have to be adjusted.

[vrutkovs]

running podman within podman does not seem to work out of the box in FedoraCOS

This needs to be reported to https://github.com/coreos/fedora-coreos-tracker/. Note that due to other bugs we're pinned to FCOS from June for now.

Currently OCS/Rook is not supported in OKD, there's no operator published in operatorhub and there's not documented way on how to install it.

This would be addressed in okd-project/okd#456

The main issue with OKD that the live iso flow wont work - since fedora missing some packages, it actually uses another disk to flush new rootfs

OKD is using Fedora CoreOS (it only has podman and no kubelet/crio) and configures bootstrap to pull in machine-os-content and pivots bootstrap node to it (so that a layer with crio/kubelet would be applied). This makes us use bootstrap-in-place schema using two writable disks - one disk for bootstrap content and one for master (and this requires manual disk swap on reboot).

Another gap is that our auth is based on PS - and this will have to be adjusted

auth as in pull secret? I suppose this can be addressed later

[vrutkovs]

openshift/installer#5463 should fix two disk requirement. It leaves BootstrapInPlace.InstallationDisk setting unused (this is the disk where bootstrap node needs to be written)