-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
enable registry middleware acceptschema2 #13428
Conversation
Signed-off-by: Aaron Weitekamp <aweiteka@redhat.com>
Also need to change the default here https://github.com/openshift/origin/blob/master/pkg/dockerregistry/server/repositorymiddleware.go#L173 |
cc @vbatts |
Also need to double check Ansible. |
Yep. Also need to change the default in the middleware code and in the ansible |
Signed-off-by: Aaron Weitekamp <aweiteka@redhat.com>
Evaluated for origin testextended up to 304fba4 |
continuous-integration/openshift-jenkins/testextended FAILURE (https://ci.openshift.redhat.com/jenkins/job/test_pull_request_origin_extended/65/) (Base Commit: 010f390) (Extended Tests: core(imageapis), core(builds)) |
@miminar (carrying forward the conversation of #8938 (comment)) Does "accepting" schema2 mean "forcing" schema2? It does not sound like it would. |
@vbatts That's correct. It's up to the client, what version of schema it will upload. Setting the Do we need |
Apparently, there cannot be two different extended focus statements. |
@miminar i would honestly see if we can just jump to allowing v2.s2, skipping v2.s1, and hopefully next will be allowing oci-v1. To address your concern, how worried are we, that a newer client will push v2.s2 content, and then an older client is broken in fetching it? @mtrmac thoughts on just allowing v2.s2 format and skipping v2.s1 on the openshift registry? |
AFAIK we require docker 1.10, if not 1.12. cc @smarterclayton @sdodson @brenton @eparis to confirm. |
I would very much like |
@ncdc Here's the docker support matrix for ocp: 3.0, 3.1 = docker 1.8 |
Thanks @brenton. Given that info, I don't see any need to support schema 1 in our registry any more. Anyone disagree? |
I'm pretty sure images from registry.access.redhat.com use v2.s1. Would that no longer supporting this schema cause breakage? |
I don't think we're talking about removing support for v2.s1. We're just talking about allowing v2.s2. Right? |
What's the status on his? |
Based on the comments this is safe to merge. |
@mfojtik I recommend pulling this into the next release. Sooner than later would be good to have some time with origin testing. |
It'll have to wait until next sprint starts (4/24) |
@mfojtik ping |
That's right. To be precise, this concerns just the manifests created via a push to the integrated registry. We already allow for consuming v2.s2 either by taging or image import. @aweiteka can you please change Hmm, looking at this I believe there's a bit more work todo in our tests. @aweiteka do you perhaps want me to take over? [testextended][extended:core(builds|imageapis|images)] |
This is required for 3.6 |
[test] |
Evaluated for origin test up to 304fba4 |
continuous-integration/openshift-jenkins/test SUCCESS (https://ci.openshift.redhat.com/jenkins/job/test_pull_request_origin/1924/) (Base Commit: 90592c5) |
I'll take a look as soon as I've finished with registry pruning. re[testextended][extended:core(builds|imageapis|images)] |
The Origin testextended job could not be run again for this pull request.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
[merge][severity:blocker] Unless there's a good reason still? |
Evaluated for origin merge up to 304fba4 |
continuous-integration/openshift-jenkins/merge FAILURE (https://ci.openshift.redhat.com/jenkins/job/merge_pull_request_origin/1014/) (Base Commit: ee15d99) (PR Branch Commit: 304fba4) (Extended Tests: blocker) |
Daemmonset flake, force merging |
Signed-off-by: Aaron Weitekamp aweiteka@redhat.com