Docker Support

In my opinion, requiring a user to upload both schema1 and schema2 images is a horrible user experience.

I would prefer we mimic the Docker registry behavior here.

https://docs.docker.com/registry/compatibility/#manifest-push-with-docker-110

I think everything should be internally stored as Schema 2. The only downside, aside from having to write the on-the-fly conversion from schema 2 to schema 1, is documented on that page: a pre-1.10 Docker engine fetching an image manifest by digest would fail. Given the age of Docker 1.10 (almost 2 years according to https://docs.docker.com/release-notes/docker-engine/#1100-2016-02-04) I think that's acceptable.

So my proposal:

• write the on-the-fly conversion from schema2 to schema1
• a manifest import will convert it to schema2 if schema1 is presented. That will cover both the direct upload and the sync case

I thought some more about this, and wanted to clarify the on-the-fly aspect.

In general we want to minimize the dynamic aspect if possible, so I don't think the implementation belongs in crane.

I think that the distributor, at publish time, should take the Schema 2 image manifests and publish them both as Schema 1 and as Schema 2.

Crane would pick the right one based on the presence of the extra headers.

Pulp treats docker manifetsts like any other content unit. When a user uploads a schema1 manifest, the user expects to retrieve a schema1 manifest. When a user uploads a schema2 manifest, the user expect to retrieve a schema2 manifest. The fact that Pulp expects both schema1 and schema2 manifests to be present in the remote registry during a sync is a bug. We should file that as a separate issue. We should just add documentation stating that if the Pulp administrator has not uploaded or synced schema1 manifests, clients older than 1.10 will receive 404s when retrieving content.

i will open a separate issue which will deal with the technical part of the sync logic.

Applied in changeset bcfb898a49dbaa6f7729a763606a5d80afafdcde.