Last modified: 2014-11-07 00:24:36 UTC
We're >90 days into 2014, so according to the Data retention guidelines [1], we should not have traffic logs from 2013. Let's check that no 2013 traffic logs are around any longer and remove any relicts that we find in stat1002's /a/squids/archive. [1] http://meta.wikimedia.org/wiki/Data_retention_guidelines
Prioritization and scheduling of this bug is tracked on Mingle card https://wikimedia.mingle.thoughtworks.com/projects/analytics/cards/cards/1529
let's estimate in this sprint.
Couldn't we just rm them? It's be pretty simple to do (heck, I could do it. Assuming the permissions change hasn't gone through yet).
(In reply to Oliver Keyes from comment #3) > Couldn't we just rm them? On stat1002? Yes, we could (if we had sufficient privileges). And next they'd be back, as they have gotten rsynced over again from their various real sources :-) > It's be pretty simple to do (heck, I could do it. > Assuming the permissions change hasn't gone through yet). The permissions change has gone through.
(In reply to christian from comment #4) > (In reply to Oliver Keyes from comment #3) > > Couldn't we just rm them? > > On stat1002? Yes, we could (if we had sufficient privileges). > And next they'd be back, as they have gotten rsynced over again > from their various real sources :-) > Aha; I thought they were generated on stat2. Cool! > > It's be pretty simple to do (heck, I could do it. > > Assuming the permissions change hasn't gone through yet). > > The permissions change has gone through. Darn. Timing! :p
Need ops help on this. Deferring however painful.
It seems RT #8760 (which is about auditing log retention on stat1002) might be relevant here.
Discussions started on what to do with each directory: /a/squid/archive api arabic-banner bannerImpressions blog edits edits-geocoded glam_nara mobile mobile-geocoded sampled sampled-geocoded sopa teahouse zero