Bug 1586336

Summary: The checksum type configuration of yum distributor should always fallback to the scratchped if it is not explicitly set to use a particular checksum type by the user.
Product: Red Hat Satellite 6 Reporter: Hao Chang Yu <hyu>
Component: PulpAssignee: satellite6-bugs <satellite6-bugs>
Status: CLOSED ERRATA QA Contact: jcallaha
Severity: medium Docs Contact:
Priority: unspecified    
Version: 6.3.1CC: afox, ajambhul, akarimi, avroy, bkearney, cmarinea, daviddavis, dcarmich, dkliban, janarula, kelly.brown1, mmccune, patalber, pcreech, rchan, rraghuwa, satellite6-bugs, shisingh, smajumda, smutkule, stefan.heijmans, ttereshc, vvasilev, wclark
Target Milestone: 6.5.0Keywords: PrioBumpGSS, Triaged
Target Release: Unused   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1661290 (view as bug list) Environment:
Last Closed: 2019-05-14 12:37:23 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
sha1
none
sha256 none

Description Hao Chang Yu 2018-06-06 02:28:55 UTC
When the checksum type of the upstream repository changed, syncing a "on_demand" repository will fail with the following error:
------------
Checksum type "sha1" is not available for all units in the repository. Make sure those units have been downloaded
------------

When syncing a repository, Pulp will update the checksum type in the repo scratchpad to match the checksum type of the upstream repository, but the checksum_type configuration in the distributor will remain no change. This will cause the above error due to data/configuration inconsistency.

The "get_repo_checksum_type" function in [1] will attempt to save the checksum type to the distributor configuration if it is not already set. In my opinion, It should not save the checksum type after falling back to the scratchpad. If the checksum type for the distributor is not explicitly set, it should always fallback to the scratchpad.

In other word, the distributor should follow the checksum type of the metadata when it is not explicitly set to use other checksum type by the user.

[1] https://github.com/pulp/pulp_rpm/blob/master/plugins/pulp_rpm/plugins/distributors/yum/configuration.py#L345

Comment 1 pulp-infra@redhat.com 2018-06-06 13:52:41 UTC
The Pulp upstream bug status is at NEW. Updating the external tracker on this bug.

Comment 2 pulp-infra@redhat.com 2018-06-06 13:52:44 UTC
The Pulp upstream bug priority is at Normal. Updating the external tracker on this bug.

Comment 6 pulp-infra@redhat.com 2018-06-29 11:59:47 UTC
The Pulp upstream bug status is at ASSIGNED. Updating the external tracker on this bug.

Comment 7 pulp-infra@redhat.com 2018-07-02 19:18:47 UTC
The Pulp upstream bug status is at POST. Updating the external tracker on this bug.

Comment 9 pulp-infra@redhat.com 2018-07-10 14:08:19 UTC
The Pulp upstream bug status is at MODIFIED. Updating the external tracker on this bug.

Comment 10 pulp-infra@redhat.com 2018-07-10 14:20:11 UTC
All upstream Pulp bugs are at MODIFIED+. Moving this bug to POST.

Comment 11 pulp-infra@redhat.com 2018-08-01 18:35:21 UTC
The Pulp upstream bug status is at ON_QA. Updating the external tracker on this bug.

Comment 12 pulp-infra@redhat.com 2018-08-03 18:03:37 UTC
The Pulp upstream bug status is at CLOSED - CURRENTRELEASE. Updating the external tracker on this bug.

Comment 19 David Davis 2018-11-06 12:51:59 UTC
Anand,

As the customer experienced this problem without having changed the checksum_type, then this is the same bug.

Comment 27 David Davis 2018-11-29 17:36:32 UTC
I just went through this so here are the steps to reproduce.

On your Satellite box:

$ mkdir /myrepo
$ chmod -R 777 /myrepo
$ cd /myrepo
# wget some packages
$ createrepo -s sha1 /myrepo

Now create a repo and set the feed url to "file:///myrepo/" and the download policy to "On Demand" and sync it.

Now back on your Satellite box:

$ cd /myrepo
$ createrepo -s sha256 /myrepo

And now sync again. If it doesn't error, you are good. Also, confirm the # of packages.

Comment 29 jcallaha 2019-01-17 21:50:51 UTC

I followed the steps outlined in #27.


-bash-4.2# createrepo -s sha1 .
Warning: It is more compatible to use sha instead of sha1
Spawning worker 0 with 418 pkgs
Spawning worker 1 with 418 pkgs
Spawning worker 2 with 417 pkgs
Spawning worker 3 with 417 pkgs
Spawning worker 4 with 417 pkgs
Spawning worker 5 with 417 pkgs
Spawning worker 6 with 417 pkgs
Spawning worker 7 with 417 pkgs
Spawning worker 8 with 417 pkgs
Spawning worker 9 with 417 pkgs
Spawning worker 10 with 417 pkgs
Spawning worker 11 with 417 pkgs
Workers Finished
Saving Primary metadata
Saving file lists metadata
Saving other metadata
Generating sqlite DBs
Sqlite DBs complete

-bash-4.2# podman run -d -p 1337:80 -v $(pwd):/usr/local/apache2/htdocs/:Z httpd
9dc85fdb641ef073f374bbf2c8f23d79896792443db64338b906b2c7f51edbc0

-bash-4.2# podman ps
CONTAINER ID  IMAGE                           COMMAND           CREATED        STATUS            PORTS                 NAMES
9dc85fdb641e  docker.io/library/httpd:latest  httpd-foreground  3 seconds ago  Up 3 seconds ago  0.0.0.0:1337->80/tcp  sleepy_northcutt

*** Sync the repository ***

-bash-4.2# createrepo -s sha256 .
Spawning worker 0 with 418 pkgs
Spawning worker 1 with 418 pkgs
Spawning worker 2 with 417 pkgs
Spawning worker 3 with 417 pkgs
Spawning worker 4 with 417 pkgs
Spawning worker 5 with 417 pkgs
Spawning worker 6 with 417 pkgs
Spawning worker 7 with 417 pkgs
Spawning worker 8 with 417 pkgs
Spawning worker 9 with 417 pkgs
Spawning worker 10 with 417 pkgs
Spawning worker 11 with 417 pkgs
Workers Finished
Saving Primary metadata
Saving file lists metadata
Saving other metadata
Generating sqlite DBs
Sqlite DBs complete

*** ReSync the repository ***

The repository synced successfully and all package counts matched.

See attached screenshot for verification.

Comment 30 jcallaha 2019-01-17 21:51:14 UTC
Created attachment 1521377 [details]
sha1

Comment 31 jcallaha 2019-01-17 21:51:35 UTC
Created attachment 1521378 [details]
sha256

Comment 34 errata-xmlrpc 2019-05-14 12:37:23 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2019:1222