Project

Profile

Help

Issue #7414

Checksum model for distribution tree allows null value for a checksum

Added by ttereshc 10 months ago. Updated 7 months 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 8 months 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 10 months ago

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

#2 Updated by rchan 10 months ago

  • Sprint changed from Sprint 80 to Sprint 81

#3 Updated by rchan 9 months ago

  • Sprint changed from Sprint 81 to Sprint 82

#4 Updated by rchan 9 months ago

  • Sprint changed from Sprint 82 to Sprint 83

#5 Updated by ppicka 8 months ago

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

#6 Updated by ppicka 8 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 8 months ago

  • Status changed from ASSIGNED to POST

#8 Updated by rchan 8 months ago

  • Sprint changed from Sprint 83 to Sprint 84

#9 Updated by ppicka 8 months ago

  • Status changed from POST to MODIFIED

#10 Updated by dalley 7 months ago

  • Sprint/Milestone set to 3.8.0

#11 Updated by pulpbot 7 months ago

  • Status changed from MODIFIED to CLOSED - CURRENTRELEASE

Please register to edit this issue

Also available in: Atom PDF