-
Notifications
You must be signed in to change notification settings - Fork 171
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
oras attach failing for registries that don't support 1.1-RC image media type #1224
Comments
ECR strictly implements Note that In summary, this issue is a feature request to bring back the |
We chose to remove the flag For registries that implement This sounds more like a registry compatibility issue with ORAS. To address this issue, I am fine with bringing |
The slack conversation is here for reference. |
Error: PUT "https://reg.git.example.com/v2/ktarplee/test/telemetry/base/manifests/sha256:2ed182a012cd258381a134d4475d66460388fbeeb91333a3627d47a92ae6fc38": response status code 400: manifest blob unknown: blob unknown to registry |
…ras-project#1224) Signed-off-by: Jesse Butler <[email protected]>
I just hit this issue for a push, and downgrading worked for me! Specifically: wget https://github.com/oras-project/oras/releases/download/v1.0.1/oras_1.0.1_linux_amd64.tar.gz
# places ./oras in pwd
tar -xzvf oras_1.0.1_linux_amd64.tar.gz
./oras push <container> <targz>
....
Pushed [registry] ......
Digest: sha256:a93a09035767b94185b20cdec3f7bdc5331425ff9a4ddf76e5c93febf3bea390 So it's fairly easy to grab an old release, extract to just the PWD, use as needed, and you are good :) But also we should hopefully have support for a fix in the newer versions (I have 1.0.1 installed on my system, which produced the error above). |
@vsoch Do you mean 'which produced the logs above'? |
No, I was referencing the error in the original issue. |
…atibility (oras-project#1224) Signed-off-by: Jesse Butler <[email protected]>
…atibility (oras-project#1224) Signed-off-by: Jesse Butler <[email protected]>
@ktarplee From the error logs, it doesn't reveal the root cause so it is hard to determine that this is an incompatibility problem similar to this issue. Could you try to paste your complete reproduced steps and debug log (with |
Here is the full error I was getting (sorry didn't realize it wasn't here, maybe I chose the wrong issue)!:
I think the underlying issue is the registry ECR is expecting the old manifest without the artifact. |
@FeynmanZhou I looked into this a little more and I do think this is a unrelated issue. For instance, I just checked that if I use oras 1.0.1 the problem persists. So this is really a separate issue however at this point I do not know if the issue is with oras or with the gitlab registry implemention. When I get a few more hints at the problem I will open a new issue (unless you want me to open one now). |
Doesn't GitLab have an allow list for the config mediaType? That would break the ability to push any artifact that isn't pre-approved by them. If they still have that policy, I'd just mark the registry as unsupported and focus on other issues. Update: unless something has changed in the last few months, they still have an allow list for media types: |
After some offline discussions, we've aligned that chasing different RC versions of the 1.1 spec that happen to work with 1.0 registries is not the right approach. Eventually, the spec will be GA and we'll all move on with 1.0 or 1.1. The remaining value of this issue is to consider if Note, I believe this is compliant 1.0 behavior. Image spec extensibility considerations state that registries "SHOULD NOT generate an error if they encounter an unknown property in a known media type". I don't think there's specification passage that indicates a registry MUST accept unknown fields (happy to be corrected). So the decision to remove the @shizhMSFT @FeynmanZhou and other maintainers, feel free to make the call here and comment further, or close. Thanks! |
I would treat rejecting an unknown property as generating an error. To me the spirit of the statement from OCI is to allow forward compatibility, new fields can be added without fear of every new field being a breaking change that requires an upgrade of builders, registries, and runtimes. So I don't believe this is OCI compliant. I also feel that there are a number of non-OCI compliant registries out there, some intentionally so for good reasons. So it's useful for tooling to follow the robustness principle: "be conservative in what you send, be liberal in what you accept". |
Totally agree. I was more pointing at SHOULD NOT vs MUST NOT. I also completely agree that the spirit of this passage is something implementors should follow, but I don't think you can say that a registry is non-compliant if it refuses unknown fields on a known media type.
I think this is the main observation for maintainers here to consider. Not supporting this category of registries limits the use of |
It looks like the latest version of Gitlab fixed their regression with |
It seems that there have been some recent changes on the AWS ECR side which almost make it compatible with When the artifact manifest is uploaded I see the following response:
The manifest being uploaded looks something like: {
"annotations": {
"org.opencontainers.image.created": "2024-03-08T19:12:54Z"
},
"artifactType": "application/vnd.dev.sigstore.bundle+json",
"config": {
"data": "e30=",
"digest": "sha256:44136fa355b3678a1146ad16f7e8649e94fb4fc21fe77e8310c060f61caaff8a",
"mediaType": "application/vnd.oci.empty.v1+json",
"size": 2
},
"layers": [
{
"annotations": {
"org.opencontainers.image.title": "att.json"
},
"digest": "sha256:d1c3842b99b57095dccfb71e590003e2a66c701a8eff20ffd7cba1ae07e3fd3d",
"mediaType": "application/vnd.oci.image.layer.v1.tar",
"size": 5752
}
],
"mediaType": "application/vnd.oci.image.manifest.v1+json",
"schemaVersion": 2,
"subject": {
"digest": "sha256:221189b511bd1b01a233c9af11467cddb722347a2bef2162385b34034f78d212",
"mediaType": "application/vnd.oci.image.index.v1+json",
"size": 855
}
} However, I noticed that if I simply remove the It seems like this style of embedded content is optional and up to the discretion of the client. Is it worthwhile to add a flag to disable embedded content in order to achieve compatibility with AWS ECR? |
This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 30 days. |
BTW, |
What happened in your environment?
Opening a new issue to track
oras attach
failing to work for 1.0 registries (historically, issue #690 : oras attach on AWS ECR: Invalid JSON syntax). This was at one point working, so new issue to discuss more recent changes.The changes to address issue #1043 in PR #1054 is where the client dropped the
--image-spec
option. There have been subsequent changes and some refactoring here and in oras-go since then.What did you expect to happen?
With the
--image-spec
option removed, I would have expected the media type to beimage.manifest.v1
. However, without the option, attach usesimage.manifest.v1.1
without any way to select 1.0.How can we reproduce it?
With ECR:
oras attach --artifact-type some/example <registry-id>.dkr.ecr.<region>.amazonaws.com/<repo>:<tag> example.txt
Presumably, this is reproducible with any 1.0 registry that does not accept a 1.1 RC media type.
What is the version of your ORAS CLI?
1.1.0
What is your OS environment?
n/a
Are you willing to submit PRs to fix it?
The text was updated successfully, but these errors were encountered: