Bug 1991960

Summary: Fact updates causing unnecessary compliance recalculation in Candlepin
Product: [Community] Candlepin Reporter: Rehana <redakkan>
Component: candlepinAssignee: candlepin-bugs
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: high Docs Contact:
Priority: high    
Version: 3.1CC: bcourt, csnyder, dsynk, hyu, ktordeur, mjia, nmoumoul, redakkan
Target Milestone: ---Keywords: FutureFeature, Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: candlepin-4.2.1-1 Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: 1982970 Environment:
Last Closed: 2022-04-19 12:16:05 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:
Bug Depends On:    
Bug Blocks: 1982970    

Description Rehana 2021-08-10 13:35:37 UTC
+++ This bug was initially created as a clone of Bug #1982970 +++

Description of problem:
When a consumer has updated 1 or more facts, its compliance will be re-calculated by the Candlepin. This is a very expensive especially when there are many consumers (such as 20k+) registered to the Satellite and each of them have some facts update very frequently. 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:
1. On the client, ensure the 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:
In my opinion, the compliance shouldn't be re-calculated on every fact updates. Or maybe it should only be re-calculated when a certain facts that Candlepin cares has changed.


Additional info:
Let me know if you need a separate bugzilla for the syspurpose compliance hash issue above.