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.

https://github.com/pulp/pulp_rpm/pull/531

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.

This was fixed in the 2.4.1-0.1.alpha build.

Sayli,
Could please add some steps so that I can verify this.

Thanks

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.

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.

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

This was fixed in 2.4.1-0.2.alpha, available in Pulp's testing repository.

fails-qa
[root@qe-blade-08 ~]# rpm -qa pulp-server
pulp-server-2.4.1-0.2.alpha.el6.noarch
[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
kernel-3.10.0-86.el7.x86_64
[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
kernel-3.10.0-86.el7.x86_64
kernel-3.10.0-123.6.3.el7.x86_64
[root@cloud-qe-7 ~]# 


But all these were still present in the db.repo_profile_applicability

Preethi,

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.

verified

[root@qe-blade-08 ~]# rpm -qa pulp-server
pulp-server-2.4.1-0.2.alpha.el6.noarch
[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" : [ ] } }
> 


And

Also

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

This is fixed in Pulp-2.4.1-1.