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.

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

Do not maintain multiple image IDs #1020

Closed
apyrgio opened this issue Dec 2, 2024 · 0 comments · Fixed by #1021
Closed

Do not maintain multiple image IDs #1020

apyrgio opened this issue Dec 2, 2024 · 0 comments · Fixed by #1021
Labels
enhancement New feature or request

Comments

@apyrgio
Copy link
Contributor

apyrgio commented Dec 2, 2024

Currently, Dangerzone ships with two files in its share/ directory that are not part of this repo:

  • share/container.tar.gz, which is the image tarball that accompanies every new Dangerzone release.
  • share/image-id.txt, which is a file that holds all the image IDs that match the contents of this tarball.

The purpose of the image ID file is to specify what is the expected image ID in the local Podman/Docker installation. If not found, Dangerzone will load the image tarball, which takes a while. The problem with image IDs though is that they have stopped being reliable, now that Docker has introduced its own containerd image store (see #933). For this reason, as part of the release we have to get two image IDs, one for the regular image store that Docker and Podman use, and one for the containerd image store. This is a pain for several reasons:

  1. It's a release task that is not part of our CI, and is therefore not tested.
  2. It's easy to forget and ship an image-id.txt file with just one image ID.
  3. It can't be automated easily, as you would either require two separate container runtimes, or manually changing the image store of the Docker runtime.
  4. Depending on the order of image creations, we may be bitten by this bug: Podman v3 cannot load container images built with BuildKit #988

For this reason, it would be best to use a different type of image ID, such as image tags. We can tag our Dangerzone images with a unique tag, include it in the image-id.txt file, and look for the required tag in docker images / podman images, which we already do. This change should not affect the developer's and user's workflow, but it will improve the release situation a lot.

@apyrgio apyrgio added the enhancement New feature or request label Dec 2, 2024
apyrgio added a commit that referenced this issue Dec 2, 2024
Revamp the container image installation process in a way that does not
involve using image IDs. We don't want to rely on image IDs anymore,
since they are brittle (see
#933). Instead, we
use image tags, as provided in the `image-id.txt` file.  This allows us
to check fast if an image is up to date, and we no longer need to
maintain multiple image IDs from various container runtimes.

Refs #933
Refs #988
Fixes #1020
apyrgio added a commit that referenced this issue Dec 2, 2024
Revamp the container image installation process in a way that does not
involve using image IDs. We don't want to rely on image IDs anymore,
since they are brittle (see
#933). Instead, we
use image tags, as provided in the `image-id.txt` file.  This allows us
to check fast if an image is up to date, and we no longer need to
maintain multiple image IDs from various container runtimes.

Refs #933
Refs #988
Fixes #1020
apyrgio added a commit that referenced this issue Dec 2, 2024
Revamp the container image installation process in a way that does not
involve using image IDs. We don't want to rely on image IDs anymore,
since they are brittle (see
#933). Instead, we
use image tags, as provided in the `image-id.txt` file.  This allows us
to check fast if an image is up to date, and we no longer need to
maintain multiple image IDs from various container runtimes.

Refs #933
Refs #988
Fixes #1020
apyrgio added a commit that referenced this issue Dec 2, 2024
Revamp the container image installation process in a way that does not
involve using image IDs. We don't want to rely on image IDs anymore,
since they are brittle (see
#933). Instead, we
use image tags, as provided in the `image-id.txt` file.  This allows us
to check fast if an image is up to date, and we no longer need to
maintain multiple image IDs from various container runtimes.

Refs #933
Refs #988
Fixes #1020
apyrgio added a commit that referenced this issue Dec 2, 2024
Revamp the container image installation process in a way that does not
involve using image IDs. We don't want to rely on image IDs anymore,
since they are brittle (see
#933). Instead, we
use image tags, as provided in the `image-id.txt` file.  This allows us
to check fast if an image is up to date, and we no longer need to
maintain multiple image IDs from various container runtimes.

Refs #933
Refs #988
Fixes #1020
apyrgio added a commit that referenced this issue Dec 4, 2024
Revamp the container image installation process in a way that does not
involve using image IDs. We don't want to rely on image IDs anymore,
since they are brittle (see
#933). Instead, we
use image tags, as provided in the `image-id.txt` file.  This allows us
to check fast if an image is up to date, and we no longer need to
maintain multiple image IDs from various container runtimes.

Refs #933
Refs #988
Fixes #1020
apyrgio added a commit that referenced this issue Dec 9, 2024
Revamp the container image installation process in a way that does not
involve using image IDs. We don't want to rely on image IDs anymore,
since they are brittle (see
#933). Instead, we
use image tags, as provided in the `image-id.txt` file.  This allows us
to check fast if an image is up to date, and we no longer need to
maintain multiple image IDs from various container runtimes.

Refs #933
Refs #988
Fixes #1020
@github-project-automation github-project-automation bot moved this from Todo to Done in Dangerzone ✨ Dec 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

1 participant