Quadlet: allow state persistence across container restart

[lsm5]

Feature request description

Currently quadlet always removes the container when it exits. This is an issue for use cases like podmansh, where the user will expect installed packages to persist across a restart. We need an enhancement to quadlet that will preserve any changes made to the container across restarts. Perhaps in the form of a new flag Linger=true / Persistent=true .

/cc @rhatdan @pypingou @ygalblum @bachradsusi

Suggest potential solution

No response

Have you considered any alternatives?

No response

Additional context

No response

[vrothberg]

That breaks a lot of assumptions the systemd units have but I get why podmansh needs it. So we need a way to create a container once and then always use this container? How does a day-2 operation look like? How would images be updated? All data would be inside the container which I think is a risk and somehow an anti-pattern.

I have a feeling that podmansh should mount specific host paths (or volumes) in order to make data persistent and move it out of the container.

[rhatdan]

I think the maintainance of the content becomes the responsibility of the user. They need to treat it like a normal system and do their own dnf -y updates.

I see two modes.
1 Image update, which means users are not allowed to write anywhere within the image except for tmpfs and volumes mounted into the image. I envision most use cases like this, including where no volumes are mounted into the container.
2 A confined "toolbox" experience, where user gets full control over his container including the ability to become root and install additional software. In this mode the user becomes responsible for ALL software updates. Volumes can also be used in this environment.

[vrothberg]

@rhatdan, what do you think about this specific RFE? Do you think we need to support "pet" containers?

[Luap99]

For case 2 there is already the toolbox and distrobox project which are build for this use case so I don't see why qualdet/podmansh needs to support that.

Keep in mind that podmansh is in no way related to qualdet. Quadlet is just one way to start a containers with systemd and podmansh itself is a simple podman exec podmansh ..., nothing is preventing an admin to create their own systemd unit that just does podman start/stop like the old podman generate systemd to get persistence.

I think it is important to draw a line there. We did support this with podman generate systemd with and without --new and I think this caused a fair bit of complexity for us to maintain so I rather not have to deal with that again in quadlet.
Having new containers each time forces following best practices as @vrothberg mentioned, persistence should be done with volumes.

[ygalblum]

persistence should be done with volumes

This is true and simple for data. But, how will you handle package installations?

[vrothberg]

This is true and simple for data. But, how will you handle package installations?

I don't think there's silver bullet for all scenarios. But packages can also be installed on volumes if needed.

In the end it boils down to whether this is a use case or not. My immediate counter thought is: what if we need to update the image (i.e., day-2 operations)? Having persistent data inside the container mount is somehow an anti-pattern IMO.

[rhatdan]

I agree it updating an image is an anti-pattern. I would argue if you want a Pet Quadlet, then it is up to the user to maintain the packages, not an image update.

[pypingou]

On Tue, Aug 08, 2023 at 01:30:13AM -0700, Ygal Blum wrote: > persistence should be done with volumes This is true and simple for data. But, how will you handle package installations?

Update the image? :]

[ygalblum]

Update the image? :]

The use case here is that the admin configures the same base image for all users, but then each user customizes their own environment. As a result there is no updated image that includes the packages installed by the user.

[pypingou]

On Mon, Aug 14, 2023 at 04:42:57AM -0700, Ygal Blum wrote: > Update the image? :] The use case here is that the admin configures the same base image for all users, but then each user customizes their own environment. As a result there is no updated image that includes the packages installed by the user.

It sounds a bit like the experience on large compute cluster, you get an account and no priviledges whatsoever, so you end up compiling/installing the libraries and software you need in your home folder - or ask the admin to install them for everyone. So in this would be a similar situation, either a new image is made available as an option to everyone, or you use your persistent storage to compile/install the software you need

[ygalblum]

It sounds a bit like the experience on large compute cluster, you get an account and no priviledges whatsoever, so you end up compiling/installing the libraries and software you need in your home folder - or ask the admin to install them for everyone.

That's not the experience @rhatdan had in mind for podmansh. The example that triggered this issue was of creating a container in which the user can gain root privileges in her user namespace allowing her to install packages

[vrothberg]

I agree it updating an image is an anti-pattern. I would argue if you want a Pet Quadlet, then it is up to the user to maintain the packages, not an image update.

AFAIU @rhatdan agreed to not go down the "pet container" path with Quadlet.

Shall we turn this issue into a discussion to assemble ideas for patterns of using Quadlets and persistent state?