Project

Profile

Help

Issue #3139

Sync from Crane fails with "Not Found"

Added by twaugh over 2 years ago. Updated 11 months ago.

Status:
CLOSED - CURRENTRELEASE
Priority:
High
Category:
-
Sprint/Milestone:
-
Start date:
Due date:
Severity:
2. Medium
Version - Docker:
3.0.1
Platform Release:
2.15.0
Blocks Release:
Target Release - Docker:
OS:
Backwards Incompatible:
No
Triaged:
Yes
Groomed:
No
Sprint Candidate:
No
Tags:
Pulp 2
QA Contact:
Complexity:
Smash Test:
Verified:
Yes
Verification Required:
No
Sprint:
Sprint 29

Description

When syncing from a Crane repository (containing a manifest list) into a Pulp Docker repository, the sync task fails with "Not Found". I think this is because of the way it requests the image manifests within the manifest list:
https://github.com/pulp/pulp_docker/blob/pulp-docker-3.0.2-1/plugins/pulp_docker/plugins/importers/sync.py#L271

When no Accept header is set, Crane redirects to the schema-1 storage location, even though the digest may be for a schema-2 image manifests. As a result, the request fails.

Instead, the Accept header should be set to the mediaType provided in the manifest list for that manifest.

Related: https://pulp.plan.io/issues/2992

Associated revisions

Revision 5dd1ea7b View on GitHub
Added by ipanova@redhat.com about 2 years ago

Set properly the headers for the sync from Crane usecase.

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

Revision 5dd1ea7b View on GitHub
Added by ipanova@redhat.com about 2 years ago

Set properly the headers for the sync from Crane usecase.

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

Revision 5dd1ea7b View on GitHub
Added by ipanova@redhat.com about 2 years ago

Set properly the headers for the sync from Crane usecase.

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

Revision 5dd1ea7b View on GitHub
Added by ipanova@redhat.com about 2 years ago

Set properly the headers for the sync from Crane usecase.

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

Revision e734ef61 View on GitHub
Added by ipanova@redhat.com about 2 years ago

Set properly the headers for the sync from Crane usecase.

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

(cherry picked from commit 5dd1ea7b5d52be34c04a7eb0974d760583011555)

Revision e734ef61 View on GitHub
Added by ipanova@redhat.com about 2 years ago

Set properly the headers for the sync from Crane usecase.

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

(cherry picked from commit 5dd1ea7b5d52be34c04a7eb0974d760583011555)

History

#1 Updated by mhrivnak over 2 years ago

  • Priority changed from Normal to High
  • Sprint/Milestone set to 47

This looks like a blocker for use of manifest lists, and a relatively simple behavior to fix.

#2 Updated by dalley over 2 years ago

  • Triaged changed from No to Yes

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

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

#4 Updated by rchan about 2 years ago

  • Sprint/Milestone changed from 47 to 48

#5 Updated by ipanova@redhat.com about 2 years ago

  • Status changed from ASSIGNED to POST

#6 Updated by ipanova@redhat.com about 2 years ago

  • Status changed from POST to MODIFIED

#7 Updated by Ichimonji10 about 2 years ago

I tested the patch for this issue before it was merged. When packages with a fix become available, the same test procedure should be viable. To test, I spun up a pair of VMs, with hostnames of:

  • fedora-26-pulp-2-15-node1
  • fedora-26-pulp-2-15-node2

I installed Pulp 2.15 on them with the Ansible playbooks in the pulp-ci repository. This playbook also installs and configures Crane. I applied the patch Ina sent me and restarted each host. I then executed the following on the first host:

pulp-admin docker repo create --repo-id=first --feed=https://registry-1.docker.io --upstream-name=busybox
pulp-admin docker repo sync run --repo-id=first
pulp-admin docker repo publish run --repo-id=first
systemctl restart httpd  # make crane re-read metadata from disk right away
tail --follow /var/log/httpd/access_log

I then executed the following on the second host:

pulp-admin docker repo create --repo-id=second --feed=http://fedora-26-pulp-2-15-node1:5000 --upstream-name=first --verify-feed-ssl=false
pulp-admin docker repo sync run --repo-id=second
pulp-admin docker repo list --repo-id=second --details

The sync succeeded, with plenty of entries appearing in the first host's httpd access log, and with repo list on the second host showing plenty of content.

#9 Updated by pcreech about 2 years ago

  • Status changed from MODIFIED to ON_QA
  • Platform Release set to 2.15.0

#10 Updated by Ichimonji10 about 2 years ago

  • Verified changed from No to Yes

Verified with two Pulp 2.15.0 beta2 systems.

#11 Updated by Ichimonji10 about 2 years ago

@preethi This issue can be automated. However, understand that it'll be a bit difficult, as it requires the participation of multiple hosts. Basically, the test can be written, but it will only be able to be run at this time with hosts provided by an automation QE. Our Jenkins set-up can't provide multipple hosts for tests.

#12 Updated by pcreech about 2 years ago

  • Status changed from ON_QA to CLOSED - CURRENTRELEASE

#13 Updated by bmbouter almost 2 years ago

  • Sprint set to Sprint 29

#14 Updated by bmbouter almost 2 years ago

  • Sprint/Milestone deleted (48)

#15 Updated by bmbouter 11 months ago

  • Tags Pulp 2 added

Please register to edit this issue

Also available in: Atom PDF