You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
For projectbluefin.io we're shooting for a "managed toolbox" experience. We'd like the container to be set up for the user automatically, including regular updates, etc. We'd also like to fully destroy the container and rebuild it from scratch on a regular interval.
We use a volume mount to track the package manager's state so that the container is refreshed without the user losing their packaging state. This led to more discussions and I'm capturing them here:
Describe the solution you'd like
89luca89: I was thinking about distrobox assemble generate foo that would generate the assemble file from an existing unmanaged container
Then one could add a distrobox generate systemd or something on those lines, that would then create a unit file to recreate it at boot This would make it compatible with docker, podman, lilipod (and future other container managers)
This would also be useful to do "snapshots" of a container, so the assemble file would recreate it as it was in a specific time.
M2: Since everything used to create the container is in the podman inspect for the existing container, this would be parsing. Are we limited to shell or could we use jq for this functionality?
Generate systemd sounds great and should be a straightforward implenentation. Should just need the container name for making the unit file.
89luca89: The idea behind an assemble generate would be to "save/snapshot" an unmanaged container, so one where you manually installed/removed stuff, so only parsing the inspect won't be enough but yes, ideally I'd use a go-template string for the --format flag of podman inspect (or docker)
Jq or Yq (for yaml) are useful, but that would become an external dependency of the tool, which would be a first, as for now dbox only needs a posix shell and a container manager.
Is your feature request related to a problem? Please describe.
For projectbluefin.io we're shooting for a "managed toolbox" experience. We'd like the container to be set up for the user automatically, including regular updates, etc. We'd also like to fully destroy the container and rebuild it from scratch on a regular interval.
We use a volume mount to track the package manager's state so that the container is refreshed without the user losing their packaging state. This led to more discussions and I'm capturing them here:
Describe the solution you'd like
89luca89: I was thinking about
distrobox assemble generate foo
that would generate the assemble file from an existing unmanaged containerThen one could add a
distrobox generate systemd
or something on those lines, that would then create a unit file to recreate it at boot This would make it compatible with docker, podman, lilipod (and future other container managers)This would also be useful to do "snapshots" of a container, so the assemble file would recreate it as it was in a specific time.
M2: Since everything used to create the container is in the
podman inspect
for the existing container, this would be parsing. Are we limited to shell or could we use jq for this functionality?Generate systemd sounds great and should be a straightforward implenentation. Should just need the container name for making the unit file.
89luca89: The idea behind an assemble generate would be to "save/snapshot" an unmanaged container, so one where you manually installed/removed stuff, so only parsing the inspect won't be enough but yes, ideally I'd use a go-template string for the --format flag of podman inspect (or docker)
Jq or Yq (for yaml) are useful, but that would become an external dependency of the tool, which would be a first, as for now dbox only needs a posix shell and a container manager.
Describe alternatives you've considered
We're using podman's quadlets feature to do this: https://github.com/ublue-os/toolboxes/tree/main/quadlets/bluefin-cli
And here's the associated one-shot and assemble: https://github.com/ublue-os/toolboxes/tree/main/systemd/bluefin-cli
The text was updated successfully, but these errors were encountered: