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

Disable auto conversion of manifest types #782

Closed
1 task
sajayantony opened this issue Feb 3, 2023 · 4 comments · Fixed by #797
Closed
1 task

Disable auto conversion of manifest types #782

sajayantony opened this issue Feb 3, 2023 · 4 comments · Fixed by #797
Assignees
Labels
enhancement New feature or request
Milestone

Comments

@sajayantony
Copy link
Contributor

sajayantony commented Feb 3, 2023

What is the version of your ORAS CLI

0.16.0

What would you like to be added?

Currently ORAS CLI causes artifact manifest with auto fallback to image manifest. As per recent discussions in OCI https://hackmd.io/moB5-fsQTbGmDpnrsY-4yg we feel that auto conversion of manifests leads to different digests that clients may produce.

Why is this needed for ORAS?

If a registry starts supporting the artifact manifest, then ORAS CLI would start pushing the new manifest type which might potentially break downstream consumers who might know now about the this manifest type. This makes the pipeline fragile.

One option would be to make the default use --v1.1 and fail on push. And the clients can then specify --v1.0 which would only use the image manifest and continue using image manifest throughout its time until the producer chooses to push the new type.

Currrently this behavior switch depends on the target registry and moving this control to the client is the main ask here.

Are you willing to submit PRs to contribute to this feature?

  • Yes, I am willing to implement it.
@sajayantony sajayantony added the enhancement New feature or request label Feb 3, 2023
@shizhMSFT shizhMSFT added this to the v1.0.0-rc.2 milestone Feb 3, 2023
@shizhMSFT
Copy link
Contributor

The behavior of oras v1.0.0-rc.1 on the flag --image-spec is

  • Auto fallback from artifact manifest if the flag is not set
  • Push artifact manifest if the flag is set to v1.1-artifact
  • Push image manifest if the flag is set to v1.1-image

Based on @sajayantony's ask, my proposal is that the flag --image-spec will be changed to

  • Auto fallback from artifact manifest if the flag is set to v1.1-auto
  • Push artifact manifest if the flag is set to v1.1-artifact, which is marked as the default value
  • Push image manifest if the flag is set to v1.1-image

@FeynmanZhou @qweeah Any comments?

@sajayantony
Copy link
Contributor Author

With OCI coalescing around Image manifest, should we default to Image?

@FeynmanZhou
Copy link
Member

FeynmanZhou commented Feb 28, 2023

Agree with changing the default manifest type. But the user experience is supposed to be changed as follows:

  • Auto fallback is no longer needed as no valid scenario is confirmed if we change the default pushing behavior to OCI image manifest
  • Push artifact manifest if the flag --image-spec is set to v1.1-artifact,
  • Push image manifest if the flag --image-spec is set to v1.1-image, which is marked as the default value and apply to oras push and oras attach

One more note: add a Preview label to the flag --image-spec and another two commands oras attach and oras discover

@shizhMSFT
Copy link
Contributor

As discussed in the community call, the flag --image-spec will be the default to v1.1-image and the auto fallback will be removed. No new flags or flag values will be added.

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
No open projects
Status: Done
Development

Successfully merging a pull request may close this issue.

6 participants