Last modified: 2014-11-07 00:24:36 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T65543, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 63543 - Make sure 2013 traffic logs are gone from /a/squids/archive on stat1002
Make sure 2013 traffic logs are gone from /a/squids/archive on stat1002
Status: NEW
Product: Analytics
Classification: Unclassified
General/Unknown (Other open bugs)
unspecified
All All
: Normal normal
: ---
Assigned To: Nobody - You can work on this!
u=AnalyticsEng c=EventLogging p=0 s=2...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-04-04 18:57 UTC by christian
Modified: 2014-11-07 00:24 UTC (History)
5 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description christian 2014-04-04 18:57:13 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
Comment 1 Bingle 2014-04-04 19:00:23 UTC
Prioritization and scheduling of this bug is tracked on Mingle card https://wikimedia.mingle.thoughtworks.com/projects/analytics/cards/cards/1529
Comment 2 Toby Negrin 2014-04-16 20:15:38 UTC
let's estimate in this sprint.
Comment 3 Oliver Keyes 2014-04-16 20:17:54 UTC
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).
Comment 4 christian 2014-04-17 14:31:30 UTC
(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.
Comment 5 Oliver Keyes 2014-04-17 16:19:12 UTC
(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
Comment 6 Toby Negrin 2014-06-12 17:17:30 UTC
Need ops help on this. Deferring however painful.
Comment 7 christian 2014-10-28 17:46:39 UTC
It seems RT #8760 (which is about auditing log retention on stat1002) might
be relevant here.
Comment 8 Kevin Leduc 2014-11-06 00:43:31 UTC
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

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links