Description of problem: After upgrade to satellite 6.9, I can see an error message in the production logs 2021-01-26T23:37:13 [I|app|22106c00] Backtrace for 'unknown class Trend, ignoring' error (NameError): uninitialized constant Trend 22106c00 | Did you mean? Thread 22106c00 | /usr/share/foreman/app/models/filter.rb:81:in `get_resource_class' 22106c00 | /usr/share/foreman/app/models/permission.rb:22:in `block in with_translations' 22106c00 | /usr/share/foreman/app/models/permission.rb:22:in `map' 22106c00 | /usr/share/foreman/app/models/permission.rb:22:in `with_translations' 22106c00 | /usr/share/foreman/app/models/permission.rb:18:in `resources_with_translations' Version-Release number of selected component (if applicable): Satellite 6.9 How reproducible: Always Steps to Reproduce: 1. After upgrade, Try to edit any report template and check logs Additional info: I can see permission related to trends is present in the DB. It should be deleted in the upgrade irb(main):010:0> Permission.where('name LIKE ?', "%_trends") => #<ActiveRecord::Relation [#<Permission id: 171, name: "view_trends", resource_type: "Trend", created_at: "2019-08-05 21:14:09", updated_at: "2019-08-05 21:14:09">, #<Permission id: 172, name: "create_trends", resource_type: "Trend", created_at: "2019-08-05 21:14:09", updated_at: "2019-08-05 21:14:09">, #<Permission id: 173, name: "edit_trends", resource_type: "Trend", created_at: "2019-08-05 21:14:09", updated_at: "2019-08-05 21:14:09">, #<Permission id: 174, name: "destroy_trends", resource_type: "Trend", created_at: "2019-08-05 21:14:09", updated_at: "2019-08-05 21:14:09">, #<Permission id: 175, name: "update_trends", resource_type: "Trend", created_at: "2019-08-05 21:14:09", updated_at: "2019-08-05 21:14:09">]>
changing severity to low based on comment 1
While I agree, we can clean this up, this is a harmless warning, note the log level is Info. I'd keep this in 6.9 for now but wouldn't block on this in any case.
This is because the cleanup task has not been run on the instance. I agree the cleanup should happen and for downstream it should be done automatically already. Upstream we wanted to wait few versions to allow time for users to install plugin without loosing their data. This will go away once we run it for all users upstream, so unless we see more troublesome issues with this, I'd argue this doesn't need downstream specific fix prior that.
Created redmine issue https://projects.theforeman.org/issues/32116 from this bug
Hi all, this is workaroundable by running `foreman-rake purge:trends` That will get rid of all the Trends related data. This BZ should be aiming at running it automatically for all instances.
(In reply to Ondřej Ezr from comment #10) > Hi all, > > this is workaroundable by running `foreman-rake purge:trends` That will get > rid of all the Trends related data. > This BZ should be aiming at running it automatically for all instances. Thank you a lot ,Ondrej. We were doing: Permission.where('name LIKE ?', "%_trends").destroy_all : , but the purge option is much more friendly and does all the required cleanup properly. I will have a KB created for the same. -- Sayan
Created BZ https://bugzilla.redhat.com/show_bug.cgi?id=2109594 for the other two types of tracebacks related to DockerRegistry and Container resource types. The tracebacks are very similar to Trends and huge in size which can easily fill up the foreman logs.
Moving this bug to POST for triage into Satellite since the upstream issue https://projects.theforeman.org/issues/32116 has been resolved.
Verified on Satellite 6.13, upgraded from 6.9, the aforementioned messages no longer occur in logs
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 (Important: Satellite 6.13 Release), 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/RHSA-2023:2097