Setting up a purge cron job complicates installation

[Clint Byrum]

For simplicity sake, Heat should just setup a background purge process automatically. The engine could simply fork off a process that runs in the background and sleeps, waking up at a configured interval to clear out recently expired deleted items. This would make Heat much easier to install and reduce external dependencies.

[Zane Bitter (zaneb)]

I realise you have a lot more experience in operations than I, but I respectfully disagree with this. IMO some things should be deferred to external tools because (a) only the operator can make the right decision, and (b) there are battle-hardened, standard system tools to do the job far better and more reliably than anything Heat could hope to replicate.

We now support multi-engine installations - would _every_ Heat engine be periodically purging the DB?

[Clint Byrum (clint-fewbar)]

I had forgotten entirely about this bug. Let me respond to Zane's comment.

Yes, every engine could periodically purge the DB. The way I see it, they'd each wake up at some point and try to lock the 'purge' process. If they fail, they go back to sleep.

The reason I think that Heat should do this by itself is that it amounts to PostgreSQL before auto-vacuum. Before auto-vacuum, PostgreSQL administrators had _heated_ debates about when to vacuum and what it achieves and why. Now, 99.9% of the time, auto-vacuum handles the issues that people had. The few instances where auto-vacuum isn't appropriate are handled by disabling it.

In general, the less specia things the admin has to do to keep a service healthy, the less it will cost to run. Is the cron approach viable? Sure. But we absolutely _can_ do better, all by ourselves, with minimal complexity.

[Ryan Brown (sb-p)]

I agree with Clint here, having deleted items that never expire could be a nasty surprise for some deployers. Doubly so for providers that aren't very experienced and assume we need *everything* in the DB. Really it'd only need to wake up every few hours, or base it on the number of actions the engine has handled.

A couple months would be a sane default expiry if we had it as a config option, since it'd give sufficient time for a deployer to decide the right retention time before items expire by default.

[Thomas Herve (therve)]

I think we'll live with it now.

[Clint Byrum (clint-fewbar)]

Why close this bug report?