Project

Profile

Help

Story #2735

closed

Add docs about v1 protocol limitation

Added by ipanova@redhat.com over 7 years ago. Updated over 5 years ago.

Status:
CLOSED - CURRENTRELEASE
Priority:
Normal
Start date:
Due date:
% Done:

100%

Estimated time:
Platform Release:
2.14.0
Target Release - Docker:
Groomed:
Yes
Sprint Candidate:
Yes
Tags:
Documentation, Pulp 2
Sprint:
Sprint 20
Quarter:

Description

We state that are able to sync and serve both v1 and v2 content.

I tried to docker pull with newer docker client the v1 content and it is not working, unless i install older docker client.
The reason why it is not working is that docker client is not making the fail-over to v1 registry because of 302 redirect that eventually server responds with 404 html, but docker client expects a json with specific error code. This prevents docker client to failover to v1 protocol and then therefore to fetch v1 content.

In other words the current situation is : it is impossible to docker pull v1 and v2 content with one docker client version.

[ipanova@ina crane]$ pulp-admin docker repo list

+----------------------------------------------------------------------+
                          Docker Repositories
+----------------------------------------------------------------------+

Id:                  synctest
Display Name:        None
Description:         None
Content Unit Counts: 
  Docker Blob:     45
  Docker Manifest: 75
  Docker Tag:      96

Id:                  v1synctest
Display Name:        None
Description:         None
Content Unit Counts: 
  Docker Image: 27

[ipanova@ina crane]$ docker pull localhost:1234/synctest
Using default tag: latest
latest: Pulling from synctest
Digest: sha256:32f093055929dbc23dec4d03e09dfe971f5973a9ca5cf059cbfb644c206aa83f
Status: Image is up to date for localhost:1234/synctest:latest
[ipanova@ina crane]$ docker pull localhost:1234/v1synctest:1-ubuntu
Error response from daemon: error parsing HTTP 404 response body: invalid character '<' looking for beginning of value: "<!DOCTYPE HTML PUBLIC \"-//IETF//DTD HTML 2.0//EN\">\n<html><head>\n<title>404 Not Found</title>\n</head><body>\n<h1>Not Found</h1>\n<p>The requested URL /pulp/docker/v2/v1synctest/manifests/1/1-ubuntu was not found on this server.</p>\n</body></html>\n"

$ rpm -qa |grep docker
docker-engine-selinux-1.12.6-1.fc23.noarch
python-dockerfile-parse-0.0.5-4.fc24.noarch
docker-engine-1.12.6-1.fc23.x86_64

Starting from docker client 1.10 and + that behaviour is observed.
https://github.com/moby/moby/commit/a57478d65f1f5782cc746c260f9d841a0907ce54
https://github.com/moby/moby/commit/9d6acbee92016c47796ee8751dce9c59056f850d

Meanwhile with 1.9
[ipanova@ina ~]$ docker pull localhost:1234/v1synctest:1-ubuntu
Pulling repository localhost:1234/v1synctest
a6dbc8d6ddbb: Download complete 
79e69b372961: Download complete 
Status: Downloaded newer image for localhost:1234/v1synctest:1-ubuntu
localhost:1234/v1synctest: this image was pulled from a legacy registry.  Important: This registry version will not be supported in future versions of docker.
[ipanova@ina ~]$ docker pull localhost:1234/v1synctest
Using default tag: latest
Pulling repository localhost:1234/v1synctest
Tag latest not found in repository localhost:1234/v1synctest

There are just 3 reasons which would allow docker client to fallback to v1 protocol 1) 401 unauthorized 2) 404 manifest unknown 3) i do not remember

we need to implement 2 case which would look like:

    x = {"errors": [{"code": "MANIFEST_UNKNOWN","message": "manifest unknown","detail": {}}]}

    response = current_app.make_response(json.dumps(x))
    response.headers['Content-Type'] = 'application/json'
    response.headers['Docker-Distribution-API-Version'] = 'registry/2.0'
    response.status_code = 404
    return response

In order to allow crane to make such stuff ^^ this would imply changes in pulp docker publish and there would be a new redirect file version. The json metadata would contain tags for schema1_data as well.
Some changes in crane logic will need to be done accordingly. So before doing blindly the redirect, crane first would check existence of the tag in schema2_data then in schema1_data, then it would issue instead of 302, the mentioned above 404 and this would allow docker client to make the failover to v1

This changes would fix https://pulp.plan.io/issues/2536


Related issues

Related to Crane - Issue #2536: error for docker pull of non-existent tag not clearCLOSED - WONTFIXActions

Also available in: Atom PDF