Replies: 16 comments 1 reply
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
@rhatdan, what do you think about this specific RFE? Do you think we need to support "pet" containers? |
Beta Was this translation helpful? Give feedback.
-
|
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 I think it is important to draw a line there. We did support this with |
Beta Was this translation helpful? Give feedback.
-
This is true and simple for data. But, how will you handle package installations? |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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? :]
|
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
|
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
|
Beta Was this translation helpful? Give feedback.
-
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 |
Beta Was this translation helpful? Give feedback.
-
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? |
Beta Was this translation helpful? Give feedback.
-
|
Yes for now, lets leave this as a discussion and wait for real user requests for this. Might be something to discuss with the toolbox team at that time. |
Beta Was this translation helpful? Give feedback.
-
|
When porting over from I assume this is because of the I assume this is the right discussion for this even if I'm not interested in persistence per se. |
Beta Was this translation helpful? Give feedback.
-
|
The --rm should not take longer to start a container, This flag only comes into effect on container stop. You are probably seeing a different reason for the startup delay. Perhaps the container writes a lot on initialization? |
Beta Was this translation helpful? Give feedback.
-
|
I think the previous units were generated without —new. So it’s only doing
a start and not a run?
…On Fri 17 Nov 2023 at 13:43, Daniel J Walsh ***@***.***> wrote:
The --rm should not take longer to start a container, This flag only comes
into effect on container stop. You are probably seeing a different reason
for the startup delay. Perhaps the container writes a lot on initialization?
—
Reply to this email directly, view it on GitHub
<#19620 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACZDRA4EVR7QKU47JPSWDJTYE5LWLAVCNFSM6AAAAAA7ODGQOCVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TKOJYHE2DC>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Hello, to bring the discussion from https://lists.podman.io/archives/list/[email protected]/thread/PZI3ADCHR3CD44HLYM5R6GHHVRGFJ6Y4/ here - I'm fiddling with The intended goal is that a selected group of "power users" login into their own containerized environment, where they can get root privileges. This means they can install software and do some minor system configuration but sandboxed in their own container environment independent of the host OS. Following a reply on the mailinglist I could create the file [Unit]
Description=podmansh container
After=local-fs.target
ExecStartPre=-/bin/mkdir -p %h/data
RequiresMountsFor=%t/containers
[X-Container]
Image=registry.opensuse.org/opensuse/tumbleweed
ContainerName=podmansh
HostName=arctic-fox
RemapUsers=keep-id
RunInit=yes
User=1000
Volume=%h/data:%h:Z
WorkingDir=%h
Exec=sleep infinity
DropCapability=all
NoNewPrivileges=true
[Service]
ExecStartPre=/usr/bin/mkdir -p %h/data
ExecStartPre=-/usr/bin/podman create --name=podmansh --cgroups=split --init --sdnotify=conmon --user 0 -w=%h --userns=keep-id -v %h/data:%h:Z --hostname arctic-fox registry.opensuse.org/opensuse/tumbleweed sleep infinity
Environment=PODMAN_SYSTEMD_UNIT=%n
KillMode=mixed
Delegate=yes
Type=notify
NotifyAccess=all
SyslogIdentifier=%N
ExecStart=/usr/bin/podman start podmansh
[Install]
RequiredBy=default.targetThen after changing the login shell to It's still a bit bumpy and doesn't work all the time, but this might be a user story as requested by @rhatdan in #19620 (comment) |
Beta Was this translation helpful? Give feedback.
-
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
Beta Was this translation helpful? Give feedback.
All reactions