On Fri, Feb 22, 2013 at 1:29 PM, Krinkle <krinklem...@gmail.com> wrote: > Well, the obvious thing to do and imho what we should do, like, *right now* > is extend the lifetime of the old branch to the timeout of the cache. > > Simply not deleting a directory is very, very easy. > > As far as I'm concerned we can agree right now not to delete any old branch > from > the servers until further notice (until we've figured out the max time age, > and then > implement the guard in multiversion/deleteMediawiki and then remove then when > possible).
We had enough problems in the past with disk partitions filling up that this isn't as simple as it seems. While the Apaches themselves should have plenty of room now (but not infinite), there may still be other machines that builds get deployed to that have had problems with small disks and/or suboptimal partitioning. Sam has generally nuked old versions in response to something filling up (though recently, it was just the datacenter migration where we decided not to copy over old versions) We probably shouldn't pursue this strategy unless: a) we calculate a disk space budget based on the maximum number of versions to keep around, and b) we have a commitment from Ops to provide the budgeted disk space Another short term solution may be to just ensure we've got symlinks in place to fake this up (e.g. pointing 1.21wmf1 to the 1.21wmf9 subdirectory). Under the hood, it may make sense to start managing things using slots now (even still using scap rather than sartoris), which would make symlink management a lot simpler. For example, we could move the 1.21wmf9 directory to "slot0", and symlink 1.21wmf9 to that, and move 1.21wmf10 to "slot1". When it comes time to deploy 1.21wmf11, we would deploy that to slot0, and the 1.21wmf9 symlink wouldn't need to be updated. Rob _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
