Bug 2112686

Summary: ForemanPuppet::HostClass resource_type still present in database after removing puppet - excessive error logging
Product: Red Hat Satellite Reporter: Paul Armstrong <parmstro>
Component: PuppetAssignee: satellite6-bugs <satellite6-bugs>
Status: NEW --- QA Contact: Satellite QE Team <sat-qe-bz-list>
Severity: medium Docs Contact:
Priority: high    
Version: 6.11.0CC: apatel, ehelms, gtalreja, kgaikwad, minlxs, saydas
Target Milestone: UnspecifiedKeywords: Triaged
Target Release: Unused   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Paul Armstrong 2022-07-31 16:54:16 UTC 
Description of problem:
Excessive error logging due to obsolete permission in database. (I think!) 


Version-Release number of selected component (if applicable):
6.11.1

How reproducible:
Always

Steps to Reproduce:
1. Upgrade systems to 6.11.0
2. Remove puppet
3.

Actual results:
Excessive logging due to: 

2022-07-31T12:00:12 [W|app|] unknown class ForemanPuppet::HostClass, ignoring
2022-07-31T12:00:12 [I|app|] Backtrace for 'unknown class ForemanPuppet::HostClass, ignoring' error (NameError): uninitialized constant ForemanPuppet
 | /usr/share/gems/gems/foreman_hooks-0.3.17/lib/foreman_hooks/as_dependencies_hook.rb:4:in `load_missing_constant'

Expected results:
No Errors 

Additional info:
Comment 5 Sayan Das 2022-11-02 13:29:07 UTC 
JFYI, For a Sat 6.11.3 or 6.11.4, Apart from the Tracebacks related to "ForemanPuppet::HostClass" resource, I get to see the exact same tracebacks for the following resource types as well, flooding the logs.


# cat /var/log/foreman/production.log | egrep 'ForemanPuppet::' |  grep 'ignoring$' | awk '{ print $5 }' | sort | uniq -c
    837 ForemanPuppet::ConfigGroup,
   1116 ForemanPuppet::Environment,
   1116 ForemanPuppet::Puppetclass,
   1116 ForemanPuppet::PuppetclassLookupKey,


So I ended up clearing these resources as well. using the following rake sequence ( and by changing the resource type )


cat << EOF | foreman-rake console
perms = Permission.where(:resource_type => 'ForemanPuppet::HostClass')
perms.each { |perm| perm.filters.destroy_all }
perms.destroy_all
EOF


And finally a restart of services. 


Since we provide the option to run the "satellite-maintain plugin purge-puppet" command without "--remove-all-data" , It needs to be clean and there should be no huge tracebacks related to that many resources in the production log filling it up completely.
Comment 6 minlxs 2022-12-14 10:35:53 UTC 
Adding to Sayan's update, one also has to disable puppet after running "satellite-maintain plugin purge-puppet --remove-all-data":

systemctl disable --now puppet

Otherwise messages on sat and capsules will be filled with:

Dec 14 11:22:18 puppet-agent[1301]: Failed to open TCP connection to puppet:8140 (getaddrinfo: Name or service not known)
Dec 14 11:22:18 puppet-agent[1301]: No more routes to ca

Needs more QA..
Comment 7 minlxs 2022-12-14 10:36:10 UTC 
Adding to Sayan's update, one also has to disable puppet after running "satellite-maintain plugin purge-puppet --remove-all-data":

systemctl disable --now puppet

Otherwise messages on sat and capsules will be filled with:

Dec 14 11:22:18 puppet-agent[1301]: Failed to open TCP connection to puppet:8140 (getaddrinfo: Name or service not known)
Dec 14 11:22:18 puppet-agent[1301]: No more routes to ca

Needs more QA..