bootc-dev / bootc-dev/bootc

LBI: Add `/etc/bootc/bound-images.d`

Abierto
#1,237 2 comentarios 0 reacciones 0 asignados Ver en GitHub
area/logically-bound-images enhancement triaged
Lenguaje dominante
Rust
Estrellas
2.3k
Forks
230
Merge medio
3 d 12 h
PR fusionados (30 d)
38

Descripción

The problem of "agents" is long-running and difficult. With bootc we have made it trivial to embed them in the base OS image. However, while that creates a simple story and generally works, it lifecycle binds the OS to the agent, which is not always desired.

Today Fedora CoreOS basically reimplements minimal cloud support in a generic way in ignition/afterburn. cloud-init handles many things, but not all. There's vmware-guest-agent etc.

We're having some discussions in Fedora-derivative land about trying to make "generic" bootc systems, and I think one possible approach here that would feel nice is to add support for `/etc/bootc/bound-images.d` paralleling our existing `/usr/lib/bootc/bound-images.d`.

The idea here is basically that we could support shipping e.g. cloud-init or vmware-guest-agent as a privileged container, and in a `bootc install to-existing-root` scenario the installer could dynamically detect the platform at install time and add relevant agents into `/etc/bootc/bound-images.d`. So by default they'd be required for OS upgrades, and the image data would continue to live in the bootc c/storage instance. The only "mutable" state would be that their presence is requested via `/etc` and not `/usr` - decoupling them from the fully generic base OS.

OR perhaps arguably...we add dynamism to the current LBI in a systemd-style way `ConditionVirtualization=vmware` or `ConditionKernelCommandLine=ignition.platform.id=vmware` or so.

Guía de contribución

Abrir la guía de contribución

Evaluación

Este issue todavía no se ha evaluado.

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.