enki should be able to convert an image to Kairos

[jimmykarily]

Part of: #1546

When the user specified a Dockefile or a base (non-Kairos) image, the image has to be converted to Kairos the same way we do using Earthly in our release pipelines.

This conversion from vanilla OS to Kairos has a well defined logic but it's currently implemented in Earthly. We will implement it in enki instead so that we can use Auroraboot to convert vanilla images to Kairos.

Eventually, we should be able to replace the Earthly targets in our pipelines with calls to auroraboot.

[jimmykarily]

We had a discussion and this is what the process should look like:

• We take the user's Dockerfile or image
• We create a multi-stage Dockerfile that combines the user's Dockerfile/image with one from us
• In "our" part of the dockerfile, we copy over all the overlay files and binaries from the framework image
• We also generate the initramfs
• [TBD] Generate an /etc/os-release file (what info should this file include?)
• Build the multi-stage dockefile with kaniko
• Generate additional artifacts from the image (iso, etc)
• Done

To make this happen, we need to have one single framework image for all flavors/models/etc. and blindly copy
all overlay files in place. The scripts themselves should have all the logic on whether they should have any effect or not. E.g. Instead of checking in the dockerfile/earthlyfile whether to copy an overlay file, the overlay file should decide whether to do something or not, by checking if it's running on that specific model/flavor. It should use the kairos-agent to infer the needed information (e.g. like we do here)

[jimmykarily]

Created a story for the work on the overlay files: #1726

[jimmykarily]

WIP here: kairos-io/osbuilder#96

[jimmykarily]

We discussed this with Mauro and Ettore. This is what we decided to do instead of enki.

Our current Dockerfiles already implement a way to build certain flavors. The problem is that a flavor assumes a certain base image (flavor and base image go together).

We will differentiate the base image from the "strategy" (which is what we call a "flavor"). A "strategy" is a number of steps we take to configure the given base image. For example:

• building ubuntu 20.04 with the ubuntu-20.04 strategy

What this allows us to do, is to let the user build on top of any base image, using any strategy. E.g.

• build my base image which is a customized ubuntu 20.04 with the ubuntu-20.04 strategy

but also more "dangerous" things like:

• build my base image which is a customized ubuntu 18.04 with the ubuntu-20.04 strategy

This requires minimum changes to our dockerfiles. e.g.

24,25c24
< ARG BASEIMAGE
< FROM ${BASEIMAGE} AS ubuntu-upstream
---
> FROM ubuntu:rolling AS ubuntu-upstream
27c26
< FROM ${BASEIMAGE} AS ubuntu-20-lts-upstream
---
> FROM ubuntu:20.04 AS ubuntu-20-lts-upstream
29c28
< FROM ${BASEIMAGE} AS ubuntu-22-lts-upstream
---
> FROM ubuntu:22.04 AS ubuntu-22-lts-upstream

We then only have to implement some logic to select the right Dockerfile for the "strategy" the user wants (e.g. nvidia strategy is on a different dockerfile right now).

We also need to move the rest of the logic from Earthly base-image target to the Dockerfiles themselves. Then in Earthly we have very little things to do (which don't necessarily require Earthly at all).

[jimmykarily]

Closing in favor of: #1898

[jimmykarily]

Also this follow up: #1897

after #1897 , one should only need docker/kaniko in order and our Dockerfiles in order to build a Kairos container image. The rest of the story is described here: #1633 (comment)