⚠️ Build provider-kairos in this repository

[mudler]

Continuation of : #1557

We have moved the provider-kairos tests to kairos, this card is about moving the release process into kairos

Action items

• Have provider-kairos as a package
• Build k3s as a luet package (Create the k3s package using the upstream installer script packages#335)
• Move the release jobs from provider kairos to kairos
• Merge the build process such as the core image is built, and right after we build the provider image to save CI resources
• Update the release template, documentation
• QA

Open points to check:

• Adapt provider-kairos binary to pick up release list from the new location
• Check if changes to Auroraboot are needed

[Itxaka]

Currently the process to build provider enabled images on kairos is done via earthfile by running the command: PROVIDER_INSTALL https://github.com/kairos-io/provider-kairos/blob/main/Earthfile#L151

Which:

• Installs k3s version via K3S_VERSION (latest if not set)
• Installs the nohang package (Could we just move it to the base images??)
• Installs several packages from our luet repos (utils/edgevpn utils/k9s utils/nerdctl container/kubectl utils/kube-vip)
• Removes the k3s default env files (/etc/rancher/k3s/k3s.env and /etc/rancher/k3s/k3s-agent.env)
• Builds agent-provider-kairos and copies it into /system/providers/agent-provider-kairos and links it also from /usr/bin/kairos

This is set by running the earthly command with the flag --PROVIDER_KAIROS=true
This will also rerun the OSRELEASE command as its needed to override several values, otherwise the upgrades will fail, see comment at https://github.com/kairos-io/kairos/blob/master/Earthfile#L355

ISO naming is currently not changed, so that needs to be fixed. It will generate the same iso name as one without the provider on it, but as its used for testing only it did not matter that much.

Also as we are on earthly 0.6 the ARG values cannot be override inside a target. So we cannot just override the VARIANT for example with Kairos and have the iso use that and spit a decent named image, thats also the reason we need to re-run the OSBUILDER with the manual values, otherwise we could also override the OS_REPO and OSBUILDER would pick that up.
That is fixed on earthly 0.7 but it also comes with a LOT of changes to args, globalb args, etc... so its a bit more complicated than just bumping it.

[jimmykarily]

Provider kairos has a luet package: https://github.com/kairos-io/packages/tree/main/packages/bundles/provider-kairos
and so does k3s: https://github.com/kairos-io/packages/tree/main/packages/k3s

but the k3s one doesn't do all the things described on Itxaka's comment above (e.g. it doesn't create the services files), it's in TODO)

We can try to finish the k3s package and use it but I wonder if it would be better to actually call the the k3s installer script from within the luet package instead. Are we breaking some convention if a luet package makes calls to the internet? Is it supposed to be self-contained? I'm thinking that if we don't do this, we would need to always follow the logic of the installer script and make sure we replicate the same result in the luet package.

[jimmykarily]

The existing package already downloads k3s: https://github.com/kairos-io/packages/blob/fddf0ce68bf92c9dab71991ceb6d86e2c355e991/packages/k3s/build.yaml#L9

We could as well do this in the package: https://github.com/kairos-io/provider-kairos/blob/9f56a5578bfee5d0d0018d4eba7686a19939f7fb/Earthfile#L168-L172