Created attachment 923030 [details] repodata and repodata.old Description of problem: When trying to install an rpm from a yum repository managed by pulp, yum cannot install the rpm. Instead yum returns "Error: Nothing to do". Version-Release number of selected component (if applicable): 2.3.1-1 How reproducible: very Steps to Reproduce: 1. upload/copy rpm into a pulp-managed repository 2. publish repo 3. try to install an rpm from the repo 3a: if successful, repeat steps 1 and 2 Actual results: yum fails to install the rpm Expected results: yum installs the rpm Additional info: All the googling I've done has indicated this is a problem with the repo metadata (and it hasn't been resolved with `yum clean all`). ssh-ing into the pulp server and cd-ing to the repo (eg: $PATH_TO_PULP/published/http/repos/qa/$REPONAME) and running the following seems to resolve the issue temporarily: rm Packages sudo -u apache createrepo . If you try to run createrepo without first rm-ing the Pacakges symlink, createrepo shows a lot of recursion through the Packages symlink eg: Worker 1: File not found: /mnt/gca/pulp/working/repos/pulp-el6-x86_64-qa/distributors/yum_distributor/./Packages/Packages/Packages/Packages/Packages/Packages/Packages/Packages/Packages/Packages/Packages/Packages/Packages/Packages/Packages/Packages/Packages/Packages/Packages/Packages/python-pulp-rpm-common-2.3.1-1.el6.noarch.rpm I've attached a copy of repodata and repodata.old from a repo where this was happening
Please tell us what rpm you tried to install. Also, can you provide more detail about why files are being looked for in /mnt/gca/pulp instead of /var/lib/pulp ?
I don't remember exactly which rpm we were trying to install. I think it was grinder but I've been told it could be one of the pulp-rpm-* packages as well. We've made /var/lib/pulp a symlink to /mnt/gca/pulp (which is some nfs storage we've attached to the host).
Our QE verified this in 2.3.1. We are not able to reproduce it. If you still see the issue, please feel free to re-open the bug with exact steps to reproduce. Thanks.
I've been expreiencing the same issue with my internal redhat repos. achvatal and abutcher have both been very helpful at helping me workaround the issue... To reproduce internally, I interact with the avalon-re repo. juicer cart create CHGxxxx -r avalon $PRPM_LOCATIONS} From there I upload the RPMs into the avalon repo as usual: juicer cart push CHGxxxx --in re From there I update my puppet modules and then login to a FTE node and manually execute puppet with: puppet agent -t From there the server runs through all the puppet related stuff and the gives me this error (based off my bad experience with CHG5812-1): redhat-sso-cert-auth-utils-1.0.15.2-1.noarch: failure: redhat-sso-cert-auth-utils-1.0.15.2-1.noarch.rpm from avalon: [Errno 256] No more mirrors to try. redhat-gss-portal-case-management-1.0.36.0-1.noarch: failure: redhat-gss-portal-case-management-1.0.36.0-1.noarch.rpm from avalon: [Errno 256] No more mirrors to try. redhat-sso-login-module-eap6-1.0.15.2-1.noarch: failure: redhat-sso-login-module-eap6-1.0.15.2-1.noarch.rpm from avalon: [Errno 256] No more mirrors to try. I double check to ensure that my RPMs are in the repo with a show command: juicer cart show CHG5812-1 [maustin@tools02 CHG5812]$ juicer cart show CHG5812-1 { "current_env": "re", "_id": "CHG5812-1", "repos_items": { "avalon": [ "https://pulp-gca03.util.phx1.redhat.com/pulp/repos/re/avalon/redhat-gss-solrPlugin-3.1.4.1-1.noarch.rpm", "https://pulp-gca03.util.phx1.redhat.com/pulp/repos/re/avalon/redhat-sso-authenticator-eap6-1.0.15.2-1.noarch.rpm", "https://pulp-gca03.util.phx1.redhat.com/pulp/repos/re/avalon/redhat-gss-strata-model-1.0.21.6-1.noarch.rpm", "https://pulp-gca03.util.phx1.redhat.com/pulp/repos/re/avalon/redhat-gss-diagnostics-api-3.1.4.1-1.noarch.rpm", "https://pulp-gca03.util.phx1.redhat.com/pulp/repos/re/avalon/redhat-gss-mendocino-eap6-3.1.4.1-1.noarch.rpm", "https://pulp-gca03.util.phx1.redhat.com/pulp/repos/re/avalon/redhat-gss-support-services-war-1.0.19.23-1.noarch.rpm", "https://pulp-gca03.util.phx1.redhat.com/pulp/repos/re/avalon/redhat-sso-cert-auth-utils-1.0.15.2-1.noarch.rpm", "https://pulp-gca03.util.phx1.redhat.com/pulp/repos/re/avalon/redhat-gss-strata-case-management-1.0.19.23-1.noarch.rpm", "https://pulp-gca03.util.phx1.redhat.com/pulp/repos/re/avalon/redhat-gss-strata-common-1.0.19.23-1.noarch.rpm", "https://pulp-gca03.util.phx1.redhat.com/pulp/repos/re/avalon/redhat-sso-login-module-eap6-1.0.15.2-1.noarch.rpm", "https://pulp-gca03.util.phx1.redhat.com/pulp/repos/re/avalon/diagnostics-modules-3.1.4.1-1.noarch.rpm", "https://pulp-gca03.util.phx1.redhat.com/pulp/repos/re/avalon/redhat-gss-portal-2.0.14.0-1.noarch.rpm", "https://pulp-gca03.util.phx1.redhat.com/pulp/repos/re/avalon/redhat-gss-jacinto-eap6-3.1.4.1-1.noarch.rpm", "https://pulp-gca03.util.phx1.redhat.com/pulp/repos/re/avalon/redhat-gss-portal-case-management-1.0.36.0-1.noarch.rpm" ] } } You'll notice that the RPMS are indeed there. Due to an internal SSL cert problem, I did remove the https:// and switched it to http:// to workaround the issue. sed -i 's/https/http/' ~/.config/juicer/carts/CHG5812-1.json When I attempt to pull the "missing" rpms with wget over http, I'm able to download them with no errors, suggesting that they are on the server and *should* be accessible since I'm doing it from the TARGET host! When achvatal rebuilt the repo on the pulp server with a createrepo command, it resolved the problem! This happened to me during a previous release and abutcher did the same command to fix that. My fear is that we're going to keep dealing with this until some other permanantly resolution is formulated.
fyi: juicer is a CLI tool we wrote that uses the pulp api to bundle rpms together for ease of promotion between environments (ie: dev -> qa -> stage -> prod) https://github.com/juicer/juicer
Please attach a tarball of the "repodata" directory and a tree listing of all the files in the repository.
Created attachment 946403 [details] contents of the repodata directory for the avalon yum repo
Created attachment 946404 [details] directory listing for the avalon repository
Looking at the contents posted everything looks correct, the redhat-sso-cert-auth-utils-1.0.15.2-1.noarch exists in the root directory, the primary data and the sqlite database. Is it possible that what was sent is the data after createrepo was run? Also, does the database have the --generate-sqlite setting set to True?
It's possible that the contents are what was created after `createrepo` was run, but I typically rm the Packages -> . symlink that pulp creates because we've seen it cause problems too. We're using createrepo 0.9.9, which apparently has -d/--database as the default, if that's what you mean.
We believe this is fixed in 2.4. Please re-open if you can reproduce on 2.4.