On Fri, Feb 22, 2013 at 1:29 PM, Krinkle <krinklemail(a)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
