Project

Profile

Help

Issue #3258

Update with new recipe for v2s1 manifest upload

Added by ipanova@redhat.com over 3 years ago. Updated about 2 years ago.

Status:
CLOSED - CURRENTRELEASE
Priority:
Normal
Start date:
Due date:
Estimated time:
Severity:
2. Medium
Version - Docker:
Platform Release:
2.15.3
Target Release - Docker:
OS:
Triaged:
Yes
Groomed:
No
Sprint Candidate:
No
Tags:
Documentation, Pulp 2
Sprint:
Sprint 32
Quarter:

Description

skopeo added support for working with schema1.
now with option `--format` it is possible to specify which schema version s1 or s1 is wanted

--format MANIFEST TYPE, -f MANIFEST TYPE                MANIFEST TYPE (oci, v2s1, or v2s2) to use when saving image to directory using the 'dir:' transport (default is manifest type of source)

We need to update our recipes and mention the possibility of upload into Pulp v2s1.
It should be a purely doc change, code should be already prepared and functional for v2s1 upload.

I also think that we need to add a note int docs, and mention the case of sync FROM Pulp that it is necessary and it is an enforcement for user to upload v2s1 along with v2s2 for compatibility reasons or we'd need to twist pulp_docker sync logic. I am still not decided on which approach we shall take.


Related issues

Related to Docker Support - Issue #3286: Sync logic should not assume on schema1 by default existenceCLOSED - CURRENTRELEASE<a title="Actions" class="icon-only icon-actions js-contextmenu" href="#">Actions</a>

Associated revisions

Revision 93343bd0 View on GitHub
Added by ipanova@redhat.com about 3 years ago

Update with new recipe for v2s1 manifest upload.

closes #3258 https://pulp.plan.io/issues/3258

Revision 93343bd0 View on GitHub
Added by ipanova@redhat.com about 3 years ago

Update with new recipe for v2s1 manifest upload.

closes #3258 https://pulp.plan.io/issues/3258

Revision 93343bd0 View on GitHub
Added by ipanova@redhat.com about 3 years ago

Update with new recipe for v2s1 manifest upload.

closes #3258 https://pulp.plan.io/issues/3258

Revision 93343bd0 View on GitHub
Added by ipanova@redhat.com about 3 years ago

Update with new recipe for v2s1 manifest upload.

closes #3258 https://pulp.plan.io/issues/3258

Revision bcfb898a View on GitHub
Added by ipanova@redhat.com about 3 years ago

Update with new recipe for v2s1 manifest upload.

closes #3258 https://pulp.plan.io/issues/3258

(cherry picked from commit 93343bd02ed35a2fdfb9c7ff3c8c0f9f51afd32d)

Revision bcfb898a View on GitHub
Added by ipanova@redhat.com about 3 years ago

Update with new recipe for v2s1 manifest upload.

closes #3258 https://pulp.plan.io/issues/3258

(cherry picked from commit 93343bd02ed35a2fdfb9c7ff3c8c0f9f51afd32d)

History

#1 Updated by ipanova@redhat.com over 3 years ago

  • Description updated (diff)

#2 Updated by mihai.ibanescu@gmail.com over 3 years ago

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

#3 Updated by mihai.ibanescu@gmail.com over 3 years ago

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.

#4 Updated by dkliban@redhat.com over 3 years ago

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.

#5 Updated by ipanova@redhat.com over 3 years ago

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

#6 Updated by dalley over 3 years ago

  • Sprint/Milestone set to 53
  • Triaged changed from No to Yes
  • Tags Documentation added

#7 Updated by ipanova@redhat.com over 3 years ago

  • Related to Issue #3286: Sync logic should not assume on schema1 by default existence added

#8 Updated by jortel@redhat.com over 3 years ago

  • Sprint/Milestone changed from 53 to 54

#9 Updated by ipanova@redhat.com about 3 years ago

  • Status changed from NEW to ASSIGNED
  • Assignee set to ipanova@redhat.com

#10 Updated by ipanova@redhat.com about 3 years ago

  • Status changed from ASSIGNED to POST

#11 Updated by ipanova@redhat.com about 3 years ago

  • Status changed from POST to MODIFIED

#12 Updated by bmbouter about 3 years ago

  • Platform Release set to 2.15.3

#13 Updated by bmbouter about 3 years ago

  • Sprint set to Sprint 32

#14 Updated by bmbouter about 3 years ago

  • Sprint/Milestone deleted (54)

#16 Updated by bmbouter about 3 years ago

  • Status changed from MODIFIED to 5

#17 Updated by bmbouter about 3 years ago

  • Status changed from 5 to CLOSED - CURRENTRELEASE

#18 Updated by bmbouter about 2 years ago

  • Tags Pulp 2 added

Please register to edit this issue

Also available in: Atom PDF