Bug 1125438 - yum says error: nothing to do when trying to install rpm from a yum repo managed by pulp
Summary: yum says error: nothing to do when trying to install rpm from a yum repo mana...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Pulp
Classification: Retired
Component: rpm-support
Version: 2.3
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: ---
Assignee: pulp-bugs
QA Contact: pulp-qe-list
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-31 20:40 UTC by Alex Chvatal
Modified: 2014-10-15 15:57 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-10-15 15:57:47 UTC


Attachments (Terms of Use)
repodata and repodata.old (14.63 MB, application/x-gzip)
2014-07-31 20:40 UTC, Alex Chvatal
no flags Details
contents of the repodata directory for the avalon yum repo (2.80 MB, application/x-gzip)
2014-10-13 14:01 UTC, Alex Chvatal
no flags Details
directory listing for the avalon repository (227.93 KB, text/plain)
2014-10-13 14:02 UTC, Alex Chvatal
no flags Details

Description Alex Chvatal 2014-07-31 20:40:34 UTC
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

Comment 1 Michael Hrivnak 2014-08-06 16:08:15 UTC
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 ?

Comment 2 Alex Chvatal 2014-08-06 17:28:16 UTC
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).

Comment 3 Sayli Karmarkar 2014-08-08 16:07:11 UTC
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.

Comment 4 Mark Austin 2014-10-09 20:20:41 UTC
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.

Comment 5 Alex Chvatal 2014-10-09 20:26:11 UTC
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

Comment 6 Michael Hrivnak 2014-10-10 15:59:58 UTC
Please attach a tarball of the "repodata" directory and a tree listing of all the files in the repository.

Comment 7 Alex Chvatal 2014-10-13 14:01:34 UTC
Created attachment 946403 [details]
contents of the repodata directory for the avalon yum repo

Comment 8 Alex Chvatal 2014-10-13 14:02:06 UTC
Created attachment 946404 [details]
directory listing for the avalon repository

Comment 9 Barnaby Court 2014-10-13 21:18:56 UTC
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?

Comment 10 Alex Chvatal 2014-10-15 14:33:41 UTC
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.

Comment 11 Michael Hrivnak 2014-10-15 15:57:47 UTC
We believe this is fixed in 2.4. Please re-open if you can reproduce on 2.4.


Note You need to log in before you can comment on or make changes to this bug.