Migrated repos are always published with sha256 for metadata if checksum type is not explicitly configured
It's a problem for on_demand non-sha256 repos if someone tries to sync them from the migrated repos to pulp2.
#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?
#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.
- Status changed from ASSIGNED to MODIFIED
Applied in changeset pulp:pulp-2to3-migration|e8aebef13d8249cc1e220cd8f09125c7bc39da0e.
Please register to edit this issue