Issue #1389
closed
Disallow re-uploading the same package twice
Description
when pulp-admin is used for uploading rpm package that already published with same name, version and package version, but different sha and size, then yum install returns following error:
[Errno 14] PYCURL ERROR 22 - "The requested URL returned error: 416 Requested Range Not Satisfiable"
It looks like the metadata of the package is not updated, and the size of package served by http is not the same as in metadata. This causes 416 HTTP error.
Obviosly releasing of same RPM twice is a error case scenario, but the behavior of pulp is not adequate.
I see 2 possible behaviors:
1) check if package is already in the repo and reject 2-nd push
2) silently overwrite the old package with the new one, including metadata.
I leave you choosing the expected behavior.
Related issues
Updated by jortel@redhat.com over 8 years ago
- Assignee set to ipanova@redhat.com
- Triaged changed from No to Yes
Please investigate to see if this has been fixed. Mark untriaged if you find this is not true.
Updated by ipanova@redhat.com over 8 years ago
- Status changed from ASSIGNED to CLOSED - DUPLICATE
This issue is fixed in 2.6.6 https://pulp.plan.io/issues/494
I am closing this a duplicate.
Updated by jsherril@redhat.com about 7 years ago
- Status changed from CLOSED - DUPLICATE to NEW
- Version changed from 2.6.1 to 2.10.3
- Tags deleted (
Easy Fix)
Reopening as this is still an issue (tested on 2.10.3), i believe https://pulp.plan.io/issues/494 only really fixed it for syncs
Updated by bmbouter about 7 years ago
- Triaged changed from Yes to No
Untriaging as requested via IRC
Updated by igan about 7 years ago
I confirm, issue is still was observed in 2.7.0-1 but less frequently.
Updated by bizhang about 7 years ago
- Sprint/Milestone set to 33
- Triaged changed from No to Yes
Updated by ttereshc about 7 years ago
- Status changed from NEW to ASSIGNED
- Assignee set to ttereshc
Updated by ttereshc about 7 years ago
The issue occurs only after incremental publish, so the workaround is to force publish from scratch (with --force-full flag, for example).
We silently overwrite old package with a new one, but during incremental publish package metadata is added to the end of the existing metadata files, so there can be multiple references to the packages with the same NEVRA but different checksums. Duplicated metadata is also possible in metadata files.
To have N records for the package with the same NEVRA, just repeat N times:
- upload package (with the same checksums for duplicates or with different checksums to reproduce reported issue)
- publish repo
Added by ttereshc about 7 years ago
Added by ttereshc about 7 years ago
Revision 10d651cf | View on GitHub
Update last_unit_removed when unit is disassociated
It will force subsequent publish to be from scratch. Before that publish could be incremental and in some cases, like upload of the package with same NEVRA, resulted in duplicated or outdated metadata in the published repository.
Updated by ttereshc about 7 years ago
- Status changed from ASSIGNED to POST
Updated by ttereshc about 7 years ago
- Status changed from POST to MODIFIED
Applied in changeset pulp|10d651cf44d26b97f777f8b4c237b12c480cdf52.
Updated by semyers about 7 years ago
- Related to Issue #2630: disassociate_units updates last_unit_removed timestamp even if no units are removed added
Updated by bizhang about 7 years ago
- Status changed from 5 to CLOSED - CURRENTRELEASE
.
Update last_unit_removed when unit is disassociated
It will force subsequent publish to be from scratch. Before that publish could be incremental and in some cases, like upload of the package with same NEVRA, resulted in duplicated or outdated metadata in the published repository.
closes #1389 https://pulp.plan.io/issues/1389