Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
Red Hat Satellite engineering is moving the tracking of its product development work on Satellite to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "Satellite project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs will be migrated starting at the end of May. If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "Satellite project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/SAT-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
To improve performance and prevent the storage of unnecessary data, which led to reported problems with disk overflow, the `cp_events` table has been removed from the Candlepin database. The corresponding *Events* tab that was located in the Satellite web UI at *Hosts* > *Content Hosts* > *_hostname_* > *Subscriptions* has been removed.
This table grows unbound over time resulting in gigabytes of largely unecessary data. From an example customer who has a 2Y old Satellite installation with 20,000 consumers/hosts
table_name | total | index | toast | table
--------------------------------+------------+------------+------------+------------
cp_event | 12 GB | 5682 MB | 8192 bytes | 6484 MB
select count(*) from cp_event;
count
----------
25,017,125
We need a policy and procedure in place to delete anything in this table over ~7 Days (or configurable value) as it is no longer something that needs to be stored.
WORKAROUND:
This will delete all data older than 14 days as anything beyond a week isn't needed.
# echo "delete from cp_event where timestamp < now() - interval '14 days';" | sudo -u postgres psql -d candlepin
ADDITIONAL WORKAROUND:
This will setup a weekly cron to ensure continuous cleanup.
1) Download cp_event_cleanup from this Bugzilla
2) Copy to /etc/cron.weekly/
3) chmod +x /etc/cron.weekly/cp_event_cleanup
All,
I reworded this RFE to state our intentions to just cease collection of the data in the cp_event table and also remove any functionality in the Satellite 6 UI that references the Events tab in the Content Host UI.
Assigning the bug to me since I'm the owner for aha card: SAT-E-342, 343.
According to the comments in aha card, the first part of this feature can be verified:
SAT-E-342: Upgrade Sat6.5 to Sat6.6 [VERIFIED]
1). The 'cp_event' table is still existing, but it will stop writing new data to the table.
2). The 'Events' element is still existing in WebUI, but the table is null.
The second part of this feature is still developing (SAT-E-343) [Ready to develop]
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, 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-2020:1454
This table grows unbound over time resulting in gigabytes of largely unecessary data. From an example customer who has a 2Y old Satellite installation with 20,000 consumers/hosts table_name | total | index | toast | table --------------------------------+------------+------------+------------+------------ cp_event | 12 GB | 5682 MB | 8192 bytes | 6484 MB select count(*) from cp_event; count ---------- 25,017,125 We need a policy and procedure in place to delete anything in this table over ~7 Days (or configurable value) as it is no longer something that needs to be stored.