Description of problem: When a host is registered, an applicability task is kicked off for that consumer. Each task is dispatched with a reservation for 'repository_profile_applicability' resource. This is not a real resource. This causes all these tasks to be processed by a single worker. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Register a few hosts one right after another 2. Examine Pulp's database - 'reserved_resource' collection 3. Actual results: The reserved_resource collection has 'repository_profile_applicability' resource reserved. Expected results: No reserved_resource documents should exist for applicability tasks. Additional info:
The Pulp upstream bug status is at NEW. Updating the external tracker on this bug.
The Pulp upstream bug priority is at Normal. Updating the external tracker on this bug.
Per 6.3 planning, moving out non acked bugs to the backlog
The Pulp upstream bug status is at ASSIGNED. Updating the external tracker on this bug.
The Pulp upstream bug status is at CLOSED - WONTFIX. Updating the external tracker on this bug.
Quoting the upstream issue: "I suggest to use the API call for a single consumer when there is a need to calculate applicability for just one consumer (this is suitable for Katello use cases)." http://docs.pulpproject.org/dev-guide/integration/rest-api/consumer/applicability.html#generate-content-applicability-for-a-single-consumer I'm changing the component since there are no additional steps for Pulp to take. Please move it to the right component in case I've chosen the wrong one.
Moving this bug to POST for triage into Satellite 6 since the upstream issue http://projects.theforeman.org/issues/19076 has been resolved.
Once the fix was made by changing API call for, are the initial "Steps to Reproduce" still valid?
The steps in #0 are still valid. The way I've been testing it is as follows: * view qpid queue stats via 'qpid-stat -q --ssl-certificate=/etc/pki/katello/qpid_client_striped.crt -b amqps://localhost:5671 ' * subscribe some hosts to new repos * view queue stats again You should see the 'msgIn' and 'msgOut' columns increase for the 'celery' queue. Without the patch, you would see 'reserved-resource-worker-X' increase. To test this without examining the queue stats, you would need to get applicability regen to run on a large number of hosts and then check if all pulp workers were busy (new behavior), or if just one was busy (old behavior).
Worked on Satellite 6.2.10. Moving to VERIFIED.
The applicability regen did not work in some cases due to 2797. To repro: * create a new product with a yum repo for https://jlsherrill.fedorapeople.org/fake-repos/needed-errata/ * register a host, subscribe to that product, ensure katello-agent is running and package profiles are being uploaded * install https://jlsherrill.fedorapeople.org/fake-repos/needed-errata/walrus-0.71-1.noarch.rpm to host (older walrus, not newer) If no applicable errata are shown in the web UI for the host, then you have hit 2797. If one errata appears, then you're good.
The Pulp upstream bug priority is at High. Updating the external tracker on this bug.
The Pulp upstream bug status is at MODIFIED. Updating the external tracker on this bug.
Created attachment 1287373 [details] Errata available screenshot As can be seen on attached screen shot, after registering host with old repo the relate errata package was made available on Satellite. So I moved this issue to VERIFIED
The Pulp upstream bug status is at ON_QA. Updating the external tracker on this bug.
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/RHBA-2017:1553
The Pulp upstream bug status is at CLOSED - CURRENTRELEASE. Updating the external tracker on this bug.