Bug 2112686 - ForemanPuppet::HostClass resource_type still present in database after removing puppet - excessive error logging
Summary: ForemanPuppet::HostClass resource_type still present in database after removi...
Keywords:
Status: NEW
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Puppet
Version: 6.11.0
Hardware: Unspecified
OS: Unspecified
high
medium
Target Milestone: Unspecified
Assignee: satellite6-bugs
QA Contact: Satellite QE Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-07-31 16:54 UTC by Paul Armstrong
Modified: 2023-08-17 12:35 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 6985897 0 None None None 2022-11-16 20:18:49 UTC

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..


Note You need to log in before you can comment on or make changes to this bug.