Skip to content
This repository has been archived by the owner on Nov 7, 2024. It is now read-only.

key composefs/transient handling off label #607

Open
cgwalters opened this issue Mar 1, 2024 · 2 comments
Open

key composefs/transient handling off label #607

cgwalters opened this issue Mar 1, 2024 · 2 comments

Comments

@cgwalters
Copy link
Member

Per discussion related to containers/bootc#372 we want to allow configuring non-/usr content in a derived image and hence we need to stop parsing it just from the base commit.

So one strawman here is to parse a label in the metadata.

Another entirely different bigger path is to rework things to always operate on the squashed image like containers/bootc#215 does (or just target that)


Also because users may be relying /usr/local -> /var/usrlocal right now to store data we cannot automatically switch what that does if composefs happens to be enabled...at least for FCOS and existing ostree users.

@jlebon
Copy link
Member

jlebon commented Mar 1, 2024

Just going to summarize what I remember from a sync @cgwalters and I had related to this and containers/bootc#372.

  • In a composefs world, it's fine to have non-/usr top-level content. /usr is no longer special and there's no read-only bind mount just for it.
  • We keep defaulting to a read-only root (default composefs behaviour).
  • Trying to make things work in a non-composefs setup is out of scope.
  • We'll add an rpm-ostree knob to make /opt and /usr/local be directories instead of symlinks. They need to remain symlinks for compatibility, but for the new base images, we should have them default to directories.
  • We don't need state overlays or transient root configurable in the base compose. We'll focus on ensuring that enablement can happen in derived container builds instead (which is this ticket).
  • In the case of top-level non-/usr content that also needs mutability, some choices in the derived build are:
    1. Add the required symlinks to /var/... strictly where mutability is needed. This option in theory is the best one since it aligns with the r/o default, but requires knowledge of where to place the symlinks (could have e.g. docs for common packages).
    2. Enable transient root by editing the prepare-root.conf (or short-term, a label on the container, as described in this ticket).
    3. Enable state overlays on the relevant dirs by enabling instances of ostree-state-overlay@.service (e.g. on ostree-state-overlay@opt.service or ostree-state-overlay@usr-local.service).

@cgwalters
Copy link
Member Author

related PR in coreos/rpm-ostree#4850

cgwalters added a commit to cgwalters/ostree-rs-ext that referenced this issue Mar 11, 2024
cgwalters added a commit to cgwalters/rpm-ostree that referenced this issue Mar 14, 2024
cgwalters added a commit to cgwalters/rpm-ostree that referenced this issue Mar 14, 2024
cgwalters added a commit to cgwalters/rpm-ostree that referenced this issue Mar 14, 2024
xref ostreedev/ostree-rs-ext#607

We need to support having `/opt` and `/usr/local` be directly
on the rootfs.  Change the existing knob for this to be more
configurable.  The stateoverlay path is now an internal-only
knob; we expect people to do that externally.
jlebon pushed a commit to cgwalters/rpm-ostree that referenced this issue Mar 14, 2024
xref ostreedev/ostree-rs-ext#607

We need to support having `/opt` and `/usr/local` be directly
on the rootfs.  Change the existing knob for this to be more
configurable.  The stateoverlay path is now an internal-only
knob; we expect people to do that externally.
cgwalters added a commit to coreos/rpm-ostree that referenced this issue Mar 14, 2024
xref ostreedev/ostree-rs-ext#607

We need to support having `/opt` and `/usr/local` be directly
on the rootfs.  Change the existing knob for this to be more
configurable.  The stateoverlay path is now an internal-only
knob; we expect people to do that externally.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants