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

Add --multi-arch=sparse:… #1935

Open
achilleas-k opened this issue Mar 7, 2023 · 3 comments
Open

Add --multi-arch=sparse:… #1935

achilleas-k opened this issue Mar 7, 2023 · 3 comments
Labels
kind/feature A request for, or a PR adding, new functionality stale-issue

Comments

@achilleas-k
Copy link

achilleas-k commented Mar 7, 2023 •
edited
Loading

This is partially related to containers/image#1874.

Our use case (Image Builder / osbuild) requires transferring a container and its manifests (and particularly the manifest list) using a portable format that doesn't affect the image itself. We also don't want to be downloading all the images for all the architectures just to get the manifest list. In the end, it should be possible to run the container by referencing its manifest list digest without needing access to the original registry (or even an internet connection).

@mtrmac suggested using --multi-arch=index-only to store the manifest list in a dir: and then getting the image separately, which means eventually, these would need to be merged. I've used the following script to accomplish this, but I'd like confirmation that this is the right way.

Using Fedora 37 on Quay.io as an example

skopeo copy --preserve-digests docker://quay.io/fedora/fedora@sha256:176454f0e89d7bda8b8b577bfd855f5cb3854234d781855baef82cb057b0529e dir:container-archive/image

skopeo copy --preserve-digests --multi-arch=index-only docker://quay.io/fedora/fedora@sha256:176454f0e89d7bda8b8b577bfd855f5cb3854234d781855baef82cb057b0529e dir:container-archive/index
cp -a container-archive/image container-archive/merged

digest=$(sha256sum container-archive/image/manifest.json | cut -f1 -d' ')

mv container-archive/merged/manifest.json "container-archive/merged/${digest}.manifest.json"

cp container-archive/index/manifest.json container-archive/merged/manifest.json

To verify that it worked:

sudo skopeo copy --preserve-digests dir:container-archive/merged 'containers-storage:[overlay@/var/lib/containers/storage+/run/containers/storage]quay.io/fedora/fedora@sha256:176454f0e89d7bda8b8b577bfd855f5cb3854234d781855baef82cb057b0529e'
sudo podman run --rm --pull=never quay.io/fedora/fedora@sha256:176454f0e89d7bda8b8b577bfd855f5cb3854234d781855baef82cb057b0529e uname -a

runs the container without needing to pull anything.

Given the current dir: format, do you see any issues with this way of merging?

Is this something that can be added to the tooling (particularly, skopeo, either as part of the copy command or separately as a "merge" command?
@mtrmac
Copy link
Contributor

mtrmac commented Mar 7, 2023

Yes, that script looks good, with the current format of the dir: directories.

I don’t see that a “merge” operation of two dir: directories is very well-defined in general; dir: directories are typically expected to contain all components, the --index-only case being the major exception.

I think we’d want something like skopeo copy --multi-arch=sparse:[amd64,arm64] or possibly skopeo copy --sparse=[system], to preserve the original manifest list, but to only copy some of the images. That half-exists via copy.CopySpecificImages + copy.Options.Instances (where the caller can specify instances by digests, but not by platform).

A counterpart would be something like skopeo copy --multi-arch=filter:[amd64,arm64], needed by quite a few, e.g. containers/image#1707 (but not preserving the manifest list digest)

(To correctly prioritize this in the business context, please file this in Jira.)

achilleas-k added a commit to achilleas-k/osbuild that referenced this issue Mar 10, 2023
@achilleas-k
sources/skopeo: fetch index manifest for dir
f9e1438 
When the format is specified as "dir", copy the manifest specified in
the source digest and merge it into the final image directory.  The
effect of this is that the digest of the final image in the container
registry will match the manifest digest.  This enables users to specify
an image's manifest digest or a multi-image manifest list digest which
will be preserved in the container store on the final OS and allow them
to run the container using the same digest that was specified in the
input.

This may become a feature of Skopeo (or other tooling) in the future.
See containers/skopeo#1935
@achilleas-k achilleas-k mentioned this issue Mar 10, 2023
Merged
achilleas-k added a commit to achilleas-k/osbuild that referenced this issue Mar 10, 2023
@achilleas-k
sources/skopeo: fetch index manifest for dir
a1e5a8e 
When the format is specified as "dir", copy the manifest specified in
the source digest and merge it into the final image directory.  The
effect of this is that the digest of the final image in the container
registry will match the manifest digest.  This enables users to specify
an image's manifest digest or a multi-image manifest list digest which
will be preserved in the container store on the final OS and allow them
to run the container using the same digest that was specified in the
input.

This may become a feature of Skopeo (or other tooling) in the future.
See containers/skopeo#1935
achilleas-k added a commit to achilleas-k/osbuild that referenced this issue Mar 13, 2023
@achilleas-k
sources/skopeo: fetch index manifest for dir
abf603d 
When the format is specified as "dir", copy the manifest specified in
the source digest and merge it into the final image directory.  The
effect of this is that the digest of the final image in the container
registry will match the manifest digest.  This enables users to specify
an image's manifest digest or a multi-image manifest list digest which
will be preserved in the container store on the final OS.  Then, they
can run the container using the same digest that was specified in the
input.

This may become a feature of Skopeo (or other tooling) in the future.
See containers/skopeo#1935
achilleas-k added a commit to achilleas-k/osbuild that referenced this issue Mar 13, 2023
@achilleas-k
sources/skopeo: fetch index manifest for container
ae3df8a 
With the format is specified as `dir` now, we can copy the manifest
specified in the source digest and merge it into the final image
directory.  The effect of this is that the digest of the final image in
the container registry will match the manifest digest.  This enables
users to specify an image's manifest digest or a multi-image manifest
list digest which will be preserved in the container store on the final
OS.  Then, they can run the container using the same digest that was
specified in the input.

This may become a feature of Skopeo (or other tooling) in the future.
See containers/skopeo#1935
achilleas-k added a commit to achilleas-k/osbuild that referenced this issue Mar 14, 2023
@achilleas-k
sources/skopeo: fetch index manifest for container
166a023 
With the format is specified as `dir` now, we can copy the manifest
specified in the source digest and merge it into the final image
directory.  The effect of this is that the digest of the final image in
the container registry will match the manifest digest.  This enables
users to specify an image's manifest digest or a multi-image manifest
list digest which will be preserved in the container store on the final
OS.  Then, they can run the container using the same digest that was
specified in the input.

This may become a feature of Skopeo (or other tooling) in the future.
See containers/skopeo#1935
achilleas-k added a commit to achilleas-k/osbuild that referenced this issue Mar 14, 2023
@achilleas-k
sources/skopeo: fetch index manifest for container
c1be7a1 
With the local format being `dir` now, we can copy the manifest
specified in the source digest.  We can then merge the list manifest
into the image directory when requested by the user.  The effect of this
is that the digest of the final image in the container registry will
match the manifest digest.  This enables users to specify an image's
manifest digest or a multi-image manifest list digest which will be
preserved in the container store on the final OS.  Then, they can run
the container using the same digest that was specified in the input.

This may become a feature of Skopeo (or other tooling) in the future.
See containers/skopeo#1935
achilleas-k added a commit to achilleas-k/osbuild that referenced this issue Mar 15, 2023
@achilleas-k
sources/skopeo: fetch index manifest for container
61f3e57 
With the local format being `dir` now, we can copy the manifest
specified in the source digest.  We can then merge the list manifest
into the image directory when requested by the user.  The effect of this
is that the digest of the final image in the container registry will
match the manifest digest.  This enables users to specify an image's
manifest digest or a multi-image manifest list digest which will be
preserved in the container store on the final OS.  Then, they can run
the container using the same digest that was specified in the input.

Updated the module docstring with details on the storage format.
Partially copied from the containers input docstring.

This may become a feature of Skopeo (or other tooling) in the future.
See containers/skopeo#1935
@mtrmac mtrmac changed the title Merging a single image dir: with an index-only dir: Add --multi-arch=sparse:… Mar 20, 2023
@mtrmac mtrmac added the kind/feature A request for, or a PR adding, new functionality label Mar 20, 2023
@github-actions
Copy link

A friendly reminder that this issue had no activity for 30 days.

@nalind nalind mentioned this issue May 2, 2023
Open
@mtrmac mtrmac mentioned this issue May 2, 2023
Open
@snail2sky

This comment was marked as off-topic.

Sign in to view
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
kind/feature A request for, or a PR adding, new functionality stale-issue
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@achilleas-k @mtrmac @snail2sky