bootc-dev / bootc-dev/bootc

post-pull pre-stage stage (update hooks)

Offen
#640 5 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen
area/client area/config area/updates enhancement triaged
Vorherrschende Sprache
Rust
Sterne
2.3k
Forks
230
Ø Merge
3 T. 12 Std.
Gemergte PRs (30 T.)
38

Beschreibung

This relates to:

- https://github.com/containers/bootc/issues/128 (and https://github.com/containers/podman/pull/23065 )
- https://github.com/containers/bootc/issues/632
- https://github.com/containers/bootc/issues/610

Basically...I think it'd be a powerful general feature if we supported a flow that did:

- Pull new image (but without queuing a new bootloader entry)
- Run arbitrary code from the *new* image as a container
- Only on success, queue new bootloader entry

One simple way to do this would be to define a new `bootc-pre-stage.target` systemd unit that we run in between what currently happens when one types `bootc upgrade`.

This would be a clearly very powerful general mechanism that would allow implementing things like "logically bound container images" outside of bootc core code itself. A base image (or user code) could define which container images to pull via whatever mechanisms and file format it wants.

One could do arbitrary things like check compatibility (relates to #632 and #610)

The downside of course is that being so general, it'd be easy to use for things that would probably be best done elsewhere. I think we'd still eventually want higher level and more declarative/opinionated mechanisms for some of the problems here (especially the container binding one).

(This also tangentially relates to https://github.com/containers/bootc/issues/2 in that it'd probably be a bit more elegant if we internally split up bits of the bootc upgrade process internally into units)

But...in ostree we already merged e.g. which is currently a very special case.

Actually, a notable detail here is that `bootc-pre-stage.target` as proposed would get mutable access to the *current* `/etc` and the global `/var`, i.e. it'd be ordered before `ostree-finalize-staged.target`.

Beitragsleitfaden

Beitragsleitfaden öffnen

Rechercherichtung

The proposal centers on the bootc upgrade flow and ordering around ostree-finalize-staged.target, with a new bootc-pre-stage.target. Start by tracing the existing upgrade and staging sequence, then review the linked bootc issues and related Podman and ostree work. Done requires an agreed design for the proposed flow and its scope.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Bewertung

Bereich
operating-systems
Issue-Typ
Feature
Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Aktivitätsstatus
Veraltet
Klarheit
Muss geklärt werden
Anfängerfreundlichkeit
25/100

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.