Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

🏭 Consolidate osbuilder and Auroraboot #1633

Open
Tracked by #2127
jimmykarily opened this issue Jul 24, 2023 · 3 comments
Open
Tracked by #2127

🏭 Consolidate osbuilder and Auroraboot #1633

jimmykarily opened this issue Jul 24, 2023 · 3 comments
Assignees

Comments

@jimmykarily
Copy link
Contributor

jimmykarily commented Jul 24, 2023

We currently have 2 different tools to build Kairos images:

  • Auraboot, meant to be used outside Kubernetes
  • osbuilder, meant to be used as a controller inside Kubernetes
    osbuilder vs auroraboot

Both of them have more responsibilities than building (e.g. Auroraboot handles netbooting, osbuilder handles upgrades) but they share the building part.

The current situation and the desired is described in the image above.

This is an epic to collect all the steps/issues toward the desired state.

The last item needs to be discussed and it will be more clear when we have everything consolidated in one image.

@jimmykarily
Copy link
Contributor Author

jimmykarily commented Aug 1, 2023

osbuilder BYOI (https __github com_kairos-io_kairos_issues_1546)

One more image describing the desired state of the various tools (osbuilder, auroraboot, enki) and the relations between them.

@jimmykarily
Copy link
Contributor Author

We will soon be able to build Kairos container images using just Dockerfiles (no Earthly or other tools). There are 2 things missing to have the full "factory" experience:

  • A tool that produces the various other artifacts from the container image (e.g. iso, img)
  • A tool that wraps the whole flow in some nice UX

Right now the creation of additional artifacts happens in Earthly using osbuilder-tools image. Above we describe how Autoraboot should provide both the UX and the artifact building functionality. Let's consider splitting as such:

  • enki is the tool that builds all types of artifacts given a container image
  • Auroraboot is a cli interface that calls out to enki. It's meant to be used by humans.\
  • Osbuilder controller also calls out to enki. It's meant to be used in Kubernetes in a declarative way.

The new suggestion above is that osbuilder doesn't use Auroraboot but enki directly. This allows us to focus the UX of Auroraboot to humans and not try to satisfy the needs of osbuilder too. enki should be able to cover both since it will be an internal tool, with no focus on UX.

jimmykarily added a commit to kairos-io/AuroraBoot that referenced this issue Nov 1, 2024
As part of kairos-io/kairos#1633

Signed-off-by: Dimitris Karakasilis <dimitris@karakasilis.me>
jimmykarily added a commit to kairos-io/enki that referenced this issue Nov 1, 2024
so that it can be used as a library from Auroraboot
as part of kairos-io/kairos#1633

The following anti-patterns make it very hard to re-use the enki
functions:

- viper is used as a global store, randomly accessing everything from anywhere
- we pass around too many "configs": the BuildConfig, the embedded
  kairos-agent config, the BuildUKIAction (which is essentially yet another config),

It's nearly impossible to construct the proper input for any function
because we don't know what part of the configs available, is actually needed
and used.

This is a first refactoring that should at least let the caller use the
BuildUKIAction without needing to populate a global "viper" object.

Signed-off-by: Dimitris Karakasilis <dimitris@karakasilis.me>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: In Progress 🏃
Development

No branches or pull requests

1 participant