[PDB-2478] Allow triggering of GC processes via POST Created: 2016/02/29  Updated: 2017/03/15  Resolved: 2016/06/02

Status: Closed
Project: PuppetDB
Component/s: None
Affects Version/s: None
Fix Version/s: PDB 4.2.0

Type: New Feature Priority: Normal
Reporter: Ryan Senior Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: tcse
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
relates to PDB-2415 PuppetDB Should Reduce Use of Cascadi... Closed
Epic Link: GC Improvements
Story Points: 3


Currently GC background processes are triggered by a timed "duration" style background thread. This is not very flexible and can cause problems as the duration is calculated on startup. This can lead to processes running at peak times, inadvertantly. This may not happen at first, but a restart or an outage can cause the process to be restarted, duration recalculated and then a DB intensive GC operation can then cause service slowness.

We should allow the triggering of these GC tasks via a POST. This should also allow the triggering of these jobs separately/independently. User's wanting full control of the GC processes could "disable" duration GC by setting the appropriate settings to 0. Users would then use use puppet to setup cron jobs for triggering these jobs when they want them to run (at the desired frequency).

This might need to be broken into more than one ticket, but below needs to be finished to call this task complete:

  1. One new "gc" endpoint (or parameter) for each GC task
  2. Documentation on disabling current behavior
  3. Documentation on the GC tasks along with recommendations on frequency/timing
  4. POST examples in docs to trigger the new GC calls
  5. Puppet code examples on setting up the GC tasks

Comment by Ryan Senior [ 2016/02/29 ]

Daniele Sluijters this might be of interest to you as I recall having a conversation on the PuppetDB GC tasks running during peak times

Comment by Ryan Senior [ 2016/08/08 ]

Released with 4.2.0

Generated at Mon Dec 09 13:35:40 PST 2019 using JIRA 7.7.1#77002-sha1:e75ca93d5574d9409c0630b81c894d9065296414.