1112650 - Adjust TBPL's expiration policy to retain data for a shorter amount of time

Status: RESOLVED FIXED

(Data & BI Services Team :: DB: MySQL, task)

Description

[Ed Morley [:emorley]]

TBPL is hopefully going to be switched off in the next couple of months, since many users have already switched over to its replacement (Treeherder), and the remaining users will be encouraged to switch soon.

As such, we no longer need to keep the current 30 days worth of data on both production and dev (we don't have a staging, or at least it's not used), since:
a) Many of the use cases that required that amount of data are no longer relevant (eg the sheriffs have switched over to Treeherder).
b) We want to keep TBPL around only for emergencies/stragglers, and having it only retain very recent data might encourage people to switch.

I was thinking 14 days of data on production and either 14 or 7 on dev (depending on if it's easy to have different values for each).

I'm presuming we may need to make the transition from 30 days to 14 days carefully, since there will be quite a few rows that need deleting (don't know if the current script batches them). We'll also need a defrag after too I'm presuming. That said, a short TBPL downtime (I'd say < 1 hr) shouldn't be a problem, if it's quicker to just do it one hit (TBPL downtime is no longer tree closing).

Anyway feel free to WONTFIX this if it's not worth the hassle, given TBPL being switched off within the next 2-3 months - just didn't know if it would be useful to free up some resources before then.

Comment 1

[Sheeri Cabral [:sheeri]]

The way it's coded, apparently it's the same for dev and prod. So let's go with 14...

I changed the script (r98271) and it runs at 2 am server time (which is UTC, so in about 5.5 hours from now).

Let's look tomorrow and close if it's working then.

Comment 2

[Ed Morley [:emorley]]

That's great, thank you :-)

Comment 3

[Ed Morley [:emorley]]

Seems to be working well, thank you :-)