Project

Profile

Help

Issue #8725

Migrated repos are always published with sha256 for metadata if checksum type is not explicitly configured

Added by ttereshc about 1 month ago. Updated about 9 hours ago.

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

Description

It's a problem for on_demand non-sha256 repos if someone tries to sync them from the migrated repos to pulp2.

Associated revisions

Revision e8aebef1 View on GitHub
Added by ttereshc 4 days ago

Use checksum type of a package for publication if it's not explicitly configured.

This doesn't fix users in the middle of RPM plugin migration, they would need to reset RPM migration and start it again.

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

Revision e8aebef1 View on GitHub
Added by ttereshc 4 days ago

Use checksum type of a package for publication if it's not explicitly configured.

This doesn't fix users in the middle of RPM plugin migration, they would need to reset RPM migration and start it again.

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

Revision 62d54a8a View on GitHub
Added by ttereshc about 11 hours ago

Use checksum type of a package for publication if it's not explicitly configured.

This doesn't fix users in the middle of RPM plugin migration, they would need to reset RPM migration and start it again.

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

History

#1 Updated by ttereshc about 1 month ago

I see 2 options:

  • start migrating scratchpad from pulp2 repo where the remote checksum type is specified

    • this would require a django migration
    • to fix already migrated publications users need to do reset for rpm plugin before they re-run migration
  • at publication creation, look at the pulp2rpm content and take checksum type from any unit, pulp 2 doesn't support mixed checksum types for content in a repo

    • no django migration
    • if there are changes to pulp 2 repos, such publications would be fixed automatically
    • to ensure all repos are fixed, users would still need to do reset for rpm plugin before they re-run migration

Any other ideas?

#3 Updated by dalley about 1 month ago

@Tanya would there be any way with option 1 to automatically mark the appropriate assets outdated as part of the django migration, so that they are fixed (republished) on the next run of the migration plan?

#4 Updated by ttereshc about 1 month ago

It is possible for option 2 I think but probably unexpected for a user that the re-migration is very slow.
For option 1, we do not have this data, it's in pulp2 (thinking more, maybe we can go through every single repo, look at the content and get the checksum type from there but it will be a looong django migration if we are doing it )

#5 Updated by dalley about 1 month ago

If the user needs to do a reset anyway then I'd prefer biting the bullet early rather than waiting.

What I meant though, is that in pre_migrate_repo() we currently check whether the repository has changed and mark it as "is_migrated=False" if not. If there was a checksum specified, we could consider it "changed", and then marked "is_migrated=False", and then I believe that would force a re-publish for only those repos, without an explicit plugin-wide reset? I'm a bit rusty onthe migration plugin, maybe I'm missing a step.

#6 Updated by ttereshc 5 days ago

  • Status changed from NEW to ASSIGNED
  • Assignee set to ttereshc
  • Sprint set to Sprint 98

#7 Updated by ttereshc 4 days ago

  • Status changed from ASSIGNED to MODIFIED

#8 Updated by ttereshc about 15 hours ago

  • Sprint/Milestone set to 0.11.2

#9 Updated by pulpbot about 9 hours ago

  • Status changed from MODIFIED to CLOSED - CURRENTRELEASE

Please register to edit this issue

Also available in: Atom PDF