Skip to content

Purging Revamp Phase 2 #23408

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
8 tasks
jrafanie opened this issue Apr 2, 2025 · 0 comments
Open
8 tasks

Purging Revamp Phase 2 #23408

jrafanie opened this issue Apr 2, 2025 · 0 comments
Assignees

Comments

@jrafanie
Copy link
Member

jrafanie commented Apr 2, 2025

Followup to #23394

Work Items:

  • Test openshift quotas and consider dropping container quota and container quota item archiving completely, see: Add deleted_on (with index) to container_quotas, container_quota_items manageiq-schema#110 https://bugzilla.redhat.com/show_bug.cgi?id=1504560.
  • Verify destroy / delete mechanism for each purging mixin types, part 2:
    • Non-containers
      app/models/audit_event/purging.rb:    include PurgingMixin
      app/models/binary_blob/purging.rb:    include PurgingMixin
      app/models/compliance/purging.rb:    include PurgingMixin
      app/models/drift_state/purging.rb:  include PurgingMixin
      app/models/event_stream/purging.rb:    include PurgingMixin
      app/models/miq_report_result/purging.rb:  include PurgingMixin
      app/models/miq_task/purging.rb:    include PurgingMixin
      app/models/notification/purging.rb:    include PurgingMixin
      app/models/policy_event/purging.rb:    include PurgingMixin
      app/models/vim_performance_state/purging.rb:    include PurgingMixin
      
  • update purge_orphans tool to purge orphaned records for above non-containers
  • keep_reports has support for two types of values for the same setting: 1) A number of report results per report OR 2) a duration (how many months to keep results for each report). Some reports you may run a lot and some not as often. A number # of report results would help on the former scenario but duration (number of months to keep reports) would work on the latter scenario. Maybe we should split this into two settings?
  • Review/change the existing keep_* settings that are possibly wrong
    • keep_hourly_performances and keep_daily_performances being both 6 months seems incorrect. We'll have 4320 hourlies vs 180 dailies per object that's live over the those 6 months. Hourlies for trends reports only seem to go back days. Will need to see how far back chargeback reports using hourlies go back.
  • Handle container* purging differently. Their lifecycle is different. We have some tables such as event_streams, vim_performance_states, metrics_* and metric_rollups_* that are purged independently. Only vim_performance_states orphaned rows along with by date. event_streams and metrics* tables only purge by date so a container/container_group/etc. could be have been deleted but we won't purge their events or metrics* for months. Maybe they should be treated like vim_performance_states or maybe we should come up with a new way to handle them.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant