Project

Profile

Help

Issue #3258

Update with new recipe for v2s1 manifest upload

Added by ipanova@redhat.com over 1 year ago. Updated 2 months ago.

Status:
CLOSED - CURRENTRELEASE
Priority:
Normal
Category:
-
Sprint/Milestone:
-
Severity:
2. Medium
Version - Docker:
Platform Release:
2.15.3
Blocks Release:
Target Release - Docker:
OS:
Backwards Incompatible:
No
Triaged:
Yes
Groomed:
No
Sprint Candidate:
No
Tags:
Documentation, Pulp 2
QA Contact:
Complexity:
Smash Test:
Verified:
No
Verification Required:
No
Sprint:
Sprint 32

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 existence CLOSED - CURRENTRELEASE Actions

Associated revisions

Revision 93343bd0 View on GitHub
Added by ipanova@redhat.com over 1 year 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 over 1 year 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 over 1 year 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 over 1 year 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 1 year ago

  • Description updated (diff)

#2 Updated by mihai.ibanescu@gmail.com over 1 year 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 1 year 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 1 year 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 1 year ago

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

#6 Updated by dalley over 1 year ago

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

#7 Updated by ipanova@redhat.com over 1 year ago

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

#8 Updated by jortel@redhat.com over 1 year ago

  • Sprint/Milestone changed from 53 to 54

#9 Updated by ipanova@redhat.com over 1 year ago

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

#10 Updated by ipanova@redhat.com over 1 year ago

  • Status changed from ASSIGNED to POST

#11 Updated by ipanova@redhat.com over 1 year ago

  • Status changed from POST to MODIFIED

#12 Updated by bmbouter over 1 year ago

  • Platform Release set to 2.15.3

#13 Updated by bmbouter over 1 year ago

  • Sprint set to Sprint 32

#14 Updated by bmbouter over 1 year ago

  • Sprint/Milestone deleted (54)

#16 Updated by bmbouter over 1 year ago

  • Status changed from MODIFIED to ON_QA

#17 Updated by bmbouter over 1 year ago

  • Status changed from ON_QA to CLOSED - CURRENTRELEASE

#18 Updated by bmbouter 2 months ago

  • Tags Pulp 2 added

Please register to edit this issue

Also available in: Atom PDF