Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Updating embedded OCI image does not update container #823

Closed
troglobit opened this issue Nov 13, 2024 · 0 comments · Fixed by #826
Closed

Updating embedded OCI image does not update container #823

troglobit opened this issue Nov 13, 2024 · 0 comments · Fixed by #826
Assignees
@troglobit
Labels
bug Something isn't working
Milestone
Infix v24.11

Comments

@troglobit
Copy link
Contributor

One customer reports that updating an OCI image that is embedded in the Infix image, followed by upgrading a system with that new Infix image, does not upgrade the containers using that OCI image. This behavior appears counter intuitive and does not "feel in the spirit of Infix, e.g. the immutability aspects.".

The Infix core team agrees with this statement.

Other observations:

  • The container "lifecycle" appears to users as disjunct from Infix startup-config
  • Starting a container at boot should be same as at creation or when calling container upgrade ...
  • Same with changes to Infix running-config, e.g., Container environment variables do not bite in container #822, container related changes should always be applied and restart the container

To achieve this the default behavior must change, i.e., no default writable layer by Podman:

infix/doc/container.md

Lines 86 to 92 in 032a51b

The second create a container with a semi-persistent writable layer that
survives container restarts and host system restarts. However, if you
change the container configuration or upgrade the image (see below), the
container will be recreated and the writable layer is lost. This is why
it is recommended to set up a named volume for directories, or use file
[Content Mounts](#content-mounts), in your container if you want truly
persistent content.

Persistence can then be selectively applied to explicit container paths using volumes.
@troglobit troglobit added the bug Something isn't working label Nov 13, 2024
@troglobit troglobit added this to the Infix v24.11 milestone Nov 13, 2024
@troglobit troglobit self-assigned this Nov 13, 2024
troglobit added a commit that referenced this issue Nov 16, 2024
@troglobit
confd: major behavior change, run container --read-only always
55be333 
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>
troglobit added a commit that referenced this issue Nov 16, 2024
@troglobit
package/execd: clean up any lingering containers at boot
3f492de 
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>
@troglobit troglobit mentioned this issue Nov 16, 2024
Merged
17 tasks
troglobit added a commit that referenced this issue Nov 18, 2024
@troglobit
confd: major behavior change, run container --read-only always
282ed50 
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>
troglobit added a commit that referenced this issue Nov 18, 2024
@troglobit
package/execd: clean up any lingering containers at boot
6d1bf54 
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>
troglobit added a commit that referenced this issue Nov 20, 2024
@troglobit
package/execd: clean up any lingering containers at boot
449fd46 
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>
@wkz wkz closed this as completed in 1347080 Nov 20, 2024
@wkz wkz closed this as completed in #826 Nov 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@troglobit troglobit

Labels
bug Something isn't working
Projects
Infix & C:o
Status: Done
Milestone
Infix v24.11
Development

Successfully merging a pull request may close this issue.

Container fixes kernelkit/infix
1 participant
@troglobit