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

Cannot use skopeo sync with digests #858

Closed
muff1nman opened this issue Mar 18, 2020 · 3 comments
Closed

Cannot use skopeo sync with digests #858

muff1nman opened this issue Mar 18, 2020 · 3 comments

Comments

@muff1nman
Copy link
Contributor

The following are all unsupported with skopeo sync with the yaml source format:

docker.io:
  images:
    rook/ceph:
      - "sha256:abd9b6b6c356958eead449869f6a75f6e47e1d04d7bfc7bde69d87319e5fbf61"
docker.io:
  images:
    rook/ceph:
      - "v1.2.4@sha256:abd9b6b6c356958eead449869f6a75f6e47e1d04d7bfc7bde69d87319e5fbf61"
docker.io:
  images:
    rook/ceph:
      - "@sha256:abd9b6b6c356958eead449869f6a75f6e47e1d04d7bfc7bde69d87319e5fbf61"

Is supporting digests in the yaml source something skopeo is open to receiving a patch for?

@mtrmac
Copy link
Contributor

mtrmac commented Mar 18, 2020

Sure, supporting digests would be useful.

Supporting the tag@digest notation is semantically problematic (see containers/buildah#1407 (comment) ) and I’d personally like to avoid it if at all possible.

muff1nman added a commit to muff1nman/skopeo that referenced this issue Apr 1, 2020
In addition, this changes the copy options to pass
CopyAllImages such that any digests referencing manifest
lists work as expected. While this is potentially a change
in behavior for previous sync incantations, it is most likely
desired as there is no option to override ones architecture
with the sync command anyways.

Signed-off-by: Andrew DeMaria <[email protected]>
muff1nman added a commit to muff1nman/skopeo that referenced this issue Apr 1, 2020
In addition, this changes the copy options to pass
CopyAllImages such that any digests referencing manifest
lists work as expected. While this is potentially a change
in behavior for previous sync incantations, it is most likely
desired as there is no option to override ones architecture
with the sync command anyways.

Signed-off-by: Andrew DeMaria <[email protected]>
muff1nman added a commit to muff1nman/skopeo that referenced this issue Apr 2, 2020
In addition, this changes the copy options to pass
CopyAllImages such that any digests referencing manifest
lists work as expected. While this is potentially a change
in behavior for previous sync incantations, it is most likely
desired as there is no option to override ones architecture
with the sync command anyways.

Signed-off-by: Andrew DeMaria <[email protected]>
muff1nman added a commit to muff1nman/skopeo that referenced this issue Jun 17, 2020
In addition, this changes the copy options to pass
CopyAllImages such that any digests referencing manifest
lists work as expected. While this is potentially a change
in behavior for previous sync incantations, it is most likely
desired as there is no option to override ones architecture
with the sync command anyways.

Signed-off-by: Andrew DeMaria <[email protected]>
muff1nman added a commit to muff1nman/skopeo that referenced this issue Jun 17, 2020
In addition, this changes the copy options to pass
CopyAllImages such that any digests referencing manifest
lists work as expected. While this is potentially a change
in behavior for previous sync incantations, it is most likely
desired as there is no option to override ones architecture
with the sync command anyways.

Signed-off-by: Andrew DeMaria <[email protected]>
muff1nman added a commit to muff1nman/skopeo that referenced this issue Jun 17, 2020
In addition, this changes the copy options to pass
CopyAllImages such that any digests referencing manifest
lists work as expected. While this is potentially a change
in behavior for previous sync incantations, it is most likely
desired as there is no option to override ones architecture
with the sync command anyways.

Signed-off-by: Andrew DeMaria <[email protected]>
muff1nman added a commit to muff1nman/skopeo that referenced this issue Aug 5, 2020
muff1nman added a commit to muff1nman/skopeo that referenced this issue Aug 5, 2020
This replicates the --all copy flag to sync to perform the same
behavior. Namely, the default is CopySystemImage unless --all is passed
which changes the behavior to CopyAllImages. While it is probably
desirable for --all to be the default as there is no option to override
ones architecture with the sync command, --all can potentially break
existing sync incantations depending on registry support. Hence
CopySystemImage remains the default.
muff1nman added a commit to muff1nman/skopeo that referenced this issue Aug 5, 2020
This replicates the --all copy flag to sync to perform the same
behavior. Namely, the default is CopySystemImage unless --all is passed
which changes the behavior to CopyAllImages. While it is probably
desirable for --all to be the default as there is no option to override
ones architecture with the sync command, --all can potentially break
existing sync incantations depending on registry support. Hence
CopySystemImage remains the default.

Signed-off-by: Andrew DeMaria <[email protected]>
muff1nman added a commit to muff1nman/skopeo that referenced this issue Aug 5, 2020
muff1nman added a commit to muff1nman/skopeo that referenced this issue Aug 5, 2020
This replicates the --all copy flag to sync to perform the same
behavior. Namely, the default is CopySystemImage unless --all is passed
which changes the behavior to CopyAllImages. While it is probably
desirable for --all to be the default as there is no option to override
ones architecture with the sync command, --all can potentially break
existing sync incantations depending on registry support. Hence
CopySystemImage remains the default.

Signed-off-by: Andrew DeMaria <[email protected]>
muff1nman added a commit to muff1nman/skopeo that referenced this issue Aug 6, 2020
This replicates the --all copy flag to sync to perform the same
behavior. Namely, the default is CopySystemImage unless --all is passed
which changes the behavior to CopyAllImages. While it is probably
desirable for --all to be the default as there is no option to override
ones architecture with the sync command, --all can potentially break
existing sync incantations depending on registry support. Hence
CopySystemImage remains the default.

Signed-off-by: Andrew DeMaria <[email protected]>
muff1nman added a commit to muff1nman/skopeo that referenced this issue Sep 16, 2020
muff1nman added a commit to muff1nman/skopeo that referenced this issue Sep 16, 2020
This replicates the --all copy flag to sync to perform the same
behavior. Namely, the default is CopySystemImage unless --all is passed
which changes the behavior to CopyAllImages. While it is probably
desirable for --all to be the default as there is no option to override
ones architecture with the sync command, --all can potentially break
existing sync incantations depending on registry support. Hence
CopySystemImage remains the default.

Signed-off-by: Andrew DeMaria <[email protected]>
@rhatdan
Copy link
Member

rhatdan commented Oct 8, 2020

Where are we on this one @muff1nman @mtrmac ?

@muff1nman
Copy link
Contributor Author

I believe this one is fully in y'alls hands as the PR for it has been waiting for a final review.

muff1nman added a commit to muff1nman/skopeo that referenced this issue Nov 16, 2020
This replicates the --all copy flag to sync to perform the same
behavior. Namely, the default is CopySystemImage unless --all is passed
which changes the behavior to CopyAllImages. While it is probably
desirable for --all to be the default as there is no option to override
ones architecture with the sync command, --all can potentially break
existing sync incantations depending on registry support. Hence
CopySystemImage remains the default.

Signed-off-by: Andrew DeMaria <[email protected]>
rhatdan added a commit that referenced this issue Nov 17, 2020
Fix #858 Add support for digests in sync
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 20, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants