Bug 2059137

Summary: Fact updates sending unnecessary compliance created events
Product: [Community] Candlepin Reporter: Nikos Moumoulidis <nmoumoul>
Component: candlepinAssignee: candlepin-bugs
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: medium Docs Contact:
Priority: unspecified    
Version: 3.1CC: candlepin-bugs, redakkan
Target Milestone: ---Keywords: Triaged
Target Release: 4.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: candlepin-4.0.17-1 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: 2059131 Environment:
Last Closed: 2022-04-15 13:53:38 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Nikos Moumoulidis 2022-02-28 09:55:08 UTC
+++ This bug was initially created as a clone of Bug #2059131 +++

Description of problem:
This bug is based from 1982970, in order to fix a specific sub-issue described in that bz. Specifically this part: "...Besides, this may also create many "compliance.created" events which can also give a lot of pressure to the messaging broker and eventually cause paging.

https://github.com/candlepin/candlepin/blob/master/src/main/java/org/candlepin/policy/js/compliance/hash/HashableStringGenerators.java#L216"


Steps to Reproduce:
0. Register the client

1. On the client, ensure that facts are updated

subscription-manager facts --update

2. Set any custom fact in /etc/rhsm/facts/
3. Stop the rhsmcertd service. we will trigger it manually later

systemctl stop rhsmcertd

4. On Satellite, tail the candlepin audit log

tail -f /var/log/candlepin/audit.log

5. On the client, run rhsmcertd immediately.

rhsmcertd -n

6. Wait for 1 mins and then kill the rhsmcertd process

Actual results:
### Recalculated twice here ###
2021-07-16 16:42:12,531 principalType=trusteduser principal=foreman_admin target=COMPLIANCE entityId=f8e8f51a-c20e-4d42-aa6d-0f5d621b530d type=CREATED owner=8ac705086e2c97c4016e2c9863b60001 eventData={"reasons":[],"status":"valid"}
2021-07-16 16:42:13,970 principalType=trusteduser principal=foreman_admin target=COMPLIANCE entityId=f8e8f51a-c20e-4d42-aa6d-0f5d621b530d type=CREATED owner=8ac705086e2c97c4016e2c9863b60001 eventData={"reasons":[],"status":"valid"}

2021-07-16 16:42:13,977 principalType=trusteduser principal=foreman_admin target=SYSTEM_PURPOSE_COMPLIANCE entityId=f8e8f51a-c20e-4d42-aa6d-0f5d621b530d type=CREATED owner=8ac705086e2c97c4016e2c9863b60001 eventData={"nonCompliantUsage":null,"compliantAddOns":{},"nonCompliantRole":null,"reasons":[],"compliantSLA":{},"nonCompliantAddOns":[],"compliantRole":{},"nonCompliantSLA":null,"compliantUsage":{},"status":"not specified"}

2021-07-16 16:42:13,983 principalType=trusteduser principal=foreman_admin target=CONSUMER entityId=8ac705087a3e1670017a3e1796520001 type=MODIFIED owner=8ac705086e2c97c4016e2c9863b60001 eventData=null

### Recalculate compliance again!! This is also a bug. It seems that "syspurpose compliance" and the "subscription compliance" are sharing the same "compliancestatushash" column in the cp_consumer table so after calculating the syspurpose compliance, Candlepin will replace the column with its digest. ###
2021-07-16 16:42:19,315 principalType=trusteduser principal=foreman_admin target=COMPLIANCE entityId=f8e8f51a-c20e-4d42-aa6d-0f5d621b530d type=CREATED owner=8ac705086e2c97c4016e2c9863b60001 eventData={"reasons":[],"status":"valid"} 


Expected results:
We should see no "target=COMPLIANCE type=CREATED" events being generated from step 1 onwards, since no facts that have any real effect on compliance status have changed.

Additional info:

The specific fix for this is not supposed to reduce the total amount of compliance status re-calculations, but it will reduce the amount of hash changes, which will result in (hopefully) significantly reduced amounts of "compliance.created" events being generated. This will help with the pressure on the messaging broker that caused paging.