- Reduce the amount of queues: 3 -> 1
- Simplify post hook
- Refine execd
The resulting simplification of infix_containers_post_hook(), and
touching execd, also ensure container environment variable changes
are propagated.
Fixes#822
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
To be able to handle container restarts, incl. restart policy, at
runtime, most of the container data lives in /var/lib/containers,
which on most systems is backed by a persistent store.
As of issue #823 we no longer keep a writable layer for containers,
nor should we cache container state across reboots, all containers
are recreated at boot. This task cleans up any lingering state.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Container support in Infix was released with v24.02, so this change may
unfortunately break a few use-cases out there. Regrettable as this is,
the default behavior, including how containers are started after boot,
break other use-cases that were considered more important.
As of this commit:
- all containers in Infix run in read-only mode, use volumes and
mounts for persistence across reboot/stop/start/upgrade
- all containers are now "recreated" at boot or related config changes,
this ensures an OCI image embedded in the Infix image, /lib/oci/, is
always used as the base for a running container
Fixes#823
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
This patch adds a new CLI command 'container upgrade foo', where 'foo'
is the name of the container. If more than one container use the same
image, multiple upgrades must be done because a container runs not on
the 'image:tag' but on the hash of the 'image:tag' it was created from.
Rename "done" queue to "active", since we want to recreate an active
container after fetching an updated base image.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
This patch allows containers created with "podman create" to surivce
rebots, and even reconfigurations at runtime, as long as their config
has not changed. Allowing some level of persistence in the writable
layer given to containers.
For even more persistency, support for volumes (they sync with dir in
container on first use) and mounts (creates empty writable dirs in the
container) must be added. A third option, a variant of mounts, is to
allow a leaf-list "file", where binary content can be added and then
mounted into the container, e.g.
/run/containers/files/$name/file.ext -> container://$name/etc/file.ext
None of this is available yet, but seems likely we need to add in the
very near term.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Joachim Wiberg