Bug 1118501

Summary: Kernel errata reported as applicable still after installing new kernel
Product: [Retired] Pulp Reporter: Ivan Necas <inecas>
Component: rpm-supportAssignee: Sayli Karmarkar <skarmark>
Status: CLOSED CURRENTRELEASE QA Contact: Preethi Thomas <pthomas>
Severity: unspecified Docs Contact:
Priority: high    
Version: 2.4 BetaCC: cperry, katello-bugs, katello-qa-list, mhrivnak, pthomas, rbarlow, skarmark
Target Milestone: ---Keywords: Triaged
Target Release: 2.4.1   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 1118480 Environment:
Last Closed: 2014-09-23 17:54:24 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:
Bug Depends On:    
Bug Blocks: 1118480, 1131719    

Comment 1 Michael Hrivnak 2014-07-10 22:07:56 UTC
To rephrase, our current algorithm seems to be:

IF an older EVR is installed
THEN the given rpm is applicable

but our algorithm should be:

IF an equal or newer EVR is NOT installed
THEN the given rpm is applicable

because in the case of the kernel, old versions will remain installed.

Comment 2 Sayli Karmarkar 2014-07-25 16:16:03 UTC

It looks like we were checking for the equal or newer EVR not installed in the applicability logic, but the consumer profile lookup table forming logic wasn't handling the 2 rpms with same name and arch in a consistent way. I updated the logic to create the lookup table with the newest rpm installed, which will prevent above problem.

Comment 3 Randy Barlow 2014-08-13 19:59:19 UTC
This was fixed in the 2.4.1-0.1.alpha build.

Comment 4 Preethi Thomas 2014-08-18 18:09:43 UTC
Could please add some steps so that I can verify this.


Comment 5 Randy Barlow 2014-08-20 03:31:41 UTC
We are rebasing pulp-2.4.1, and so all of these bugs can no longer be considered MODIFIED. We will need to recheck them against the rebased build to make sure the cherry picking strategy did not introduce any regressions.

Comment 6 Sayli Karmarkar 2014-08-20 06:23:32 UTC
Steps to reproduce:

1. Register a consumer with Pulp server
2. Bind a repository to the consumer which contains applicable higher version of kernel package than what is installed on the consumer (having an erratum of that kernel package is even better)
3. Generate applicability using applicabiliy api script under playpen and check that the kernel package/errata is shown applicable.
4. Install the new kernel
5. Generate applicability again and verify that the kernel is not applicable anymore.

Comment 7 Randy Barlow 2014-08-20 18:21:43 UTC
I have cherry picked this bug's commit[0] into the 2.4.1-dev branch. It appears to have applied cleanly, and all unit tests pass.

[0] https://github.com/pulp/pulp_rpm/commit/9bd12ee7ab13395dc13e5df0a6e84f1f3830f31b#diff-d41d8cd98f00b204e9800998ecf8427e

Comment 8 Randy Barlow 2014-08-20 22:16:45 UTC
This was fixed in 2.4.1-0.2.alpha, available in Pulp's testing repository.

Comment 9 Preethi Thomas 2014-08-22 17:45:37 UTC
[root@qe-blade-08 ~]# rpm -qa pulp-server
[root@qe-blade-08 ~]# 

This is failing for me. 

Here is what I did

1. Registered a consumer that had an older version of kernel
2. Bound repository with the rhel7 repo that I had synced from cdn. I had 5 kernel rpms newer than what I had installed.
3. Generated applicability using the script in playpen test_applicability_generation.py 
4. Updated kernel to a newer one.
5. Generated the applicability and it still listed all of the ones from step 3

I started with

[root@cloud-qe-7 ~]# rpm -qa kernel
[root@cloud-qe-7 ~]# 
And the repo had

> db.units_rpm.find({"name":"kernel"}, {"name":1, "version":1, "id":1, "release":1})
{ "_id" : "8779f925-9963-4f8c-bd06-b3c4251e0b3e", "version" : "3.10.0", "name" : "kernel", "release" : "123.1.2.el7" }
{ "_id" : "6a6dd49f-7c2d-46f9-8c8e-d6188c94ff4b", "version" : "3.10.0", "name" : "kernel", "release" : "123.4.2.el7" }
{ "_id" : "fc32ec01-83da-419c-8f00-a4bc30734364", "version" : "3.10.0", "name" : "kernel", "release" : "123.4.4.el7" }
{ "_id" : "ef251418-da81-45b7-8f7f-3e844a524974", "version" : "3.10.0", "name" : "kernel", "release" : "123.6.3.el7" }
{ "_id" : "4a5901b3-b090-404b-886a-513360be1cf0", "version" : "3.10.0", "name" : "kernel", "release" : "123.el7" }

And the when I updated

[root@cloud-qe-7 ~]# rpm -qa kernel
[root@cloud-qe-7 ~]# 

But all these were still present in the db.repo_profile_applicability

Comment 10 Sayli Karmarkar 2014-08-22 18:10:08 UTC

Did you look at the correct object in repo_profile_applicability collection? Your above query shows just checking in the units_rpm collection. 2 things to check are -

1. After updating the kernel package, was the consumer's profile updated and can you see the new kernel package in that profile?

2. If yes, make sure you check the correct repo_profile_applicability object corresponding to the new package profile hash. When we regenerate applicability, old repo_profile_applicability object is not deleted from the db. It is a little confusing. That is why using http://pulp-dev-guide.readthedocs.org/en/latest/integration/rest-api/consumer/applicability.html#query-content-applicability api to check for applicability will be a better way than looking at the db.

Comment 11 Preethi Thomas 2014-08-22 18:47:19 UTC

[root@qe-blade-08 ~]# rpm -qa pulp-server
[root@qe-blade-08 ~]# 

so turns out I was looking at wrong consumer profile after the update

> db.repo_profile_applicability.find({'repo_id':'rhel7', 'profile_hash': '9de2c04f85f1e70b5d130e19e9d1430de8e88151aa24c0c9a0d494595ff56365'}, {'applicability.rpm':1})
{ "_id" : ObjectId("53f77c1bf602f94c67b25fba"), "applicability" : { "rpm" : [ ] } }



>>> pic.POST('/v2/consumers/content/applicability/',body={"criteria": { "filters": {"id": {"$in": ["rhel7"]}}}})
Request Body
  "criteria": {
    "filters": {
      "id": {
        "$in": [
Response Body
    "consumers": [
    "applicability": {
      "rpm": [], 
      "erratum": []
(200, [{u'consumers': [u'rhel7'], u'applicability': {u'rpm': [], u'erratum': []}}])

Comment 12 Randy Barlow 2014-09-23 17:54:24 UTC
This is fixed in Pulp-2.4.1-1.