Project

Profile

Help

Issue #7414

Checksum model for distribution tree allows null value for a checksum

Added by ttereshc 3 months ago. Updated 15 days ago.

Status:
CLOSED - CURRENTRELEASE
Priority:
Normal
Assignee:
Sprint/Milestone:
Start date:
Due date:
Estimated time:
Severity:
2. Medium
Version:
Platform Release:
OS:
Triaged:
Yes
Groomed:
No
Sprint Candidate:
No
Tags:
Sprint:
Sprint 84
Quarter:

Description

The Checksum model for distribution tree allows a null value for the checksum field.. The checksum field is a part of uniqueness constraint. Since it's allowed to be null, and every null is unique, it's possible to have duplicates.

There is a spec (somewhat outdated) https://release-engineering.github.io/productmd/treeinfo-1.0.html which seems to say that checksums should always be present.

I'm not sure about real world examples when checksum type is null for this model, however the data migration needs to consider that theoretical possibility.

Associated revisions

Revision c56bac11 View on GitHub
Added by ppicka about 1 month ago

Checksum to not allow null

Removing allow_null from checksum field from checksum model.

closes: #7414 https://pulp.plan.io/issues/7414 [nocoverage]

History

#1 Updated by ttereshc 3 months ago

  • Triaged changed from No to Yes
  • Sprint set to Sprint 80

#2 Updated by rchan 3 months ago

  • Sprint changed from Sprint 80 to Sprint 81

#3 Updated by rchan 2 months ago

  • Sprint changed from Sprint 81 to Sprint 82

#4 Updated by rchan about 2 months ago

  • Sprint changed from Sprint 82 to Sprint 83

#5 Updated by ppicka about 2 months ago

  • Status changed from NEW to ASSIGNED
  • Assignee set to ppicka

#6 Updated by ppicka about 2 months ago

Noticed that in case of checksum missing e.g.

[checksums]
images/pxeboot/upgrade.img = sha256:30e14955ebf1352266dc2ff8067e68104607e750abb9d3b36582b8af909fcb58
images/pxeboot/vmlinuz =

productmd.treeinfo.TreeInfo used in our parsing will count hash.

fixtures/rpm-distribution-tree/addons/dolphin/repodata/repomd.xml

entry like this fail the sync

in this case do we want manual migration when 'null' can't (shouldn't) happen, and we do not save repomd.xml file to re-count its hash?

#7 Updated by pulpbot about 2 months ago

  • Status changed from ASSIGNED to POST

#8 Updated by rchan about 1 month ago

  • Sprint changed from Sprint 83 to Sprint 84

#9 Updated by ppicka about 1 month ago

  • Status changed from POST to MODIFIED

#10 Updated by dalley 16 days ago

  • Sprint/Milestone set to 3.8.0

#11 Updated by pulpbot 15 days ago

  • Status changed from MODIFIED to CLOSED - CURRENTRELEASE

Please register to edit this issue

Also available in: Atom PDF