Reducing TTL for try server builds
Nick Thomas
the try server - to 14 days instead of 30. This will help build.m.o cope
better as the try infrastructure grows, by reducing disk usage for old
builds.
If there are any reasons to not go ahead with this change, please reply
before the end of Friday PDT.
-Nick Thomas (RelEng)
John J. Barton
Better would be say 2 days, but with some way to mark special builds
with 30 days (or more). I'm guessing: the try servers have two classes
of uses,
1) "will this work on box other than the one I own?" 2days
2) "try this cool feature I think it kinda works" 30 days.
After two days the first class is forgotten or stale anyway.
(I'm interested in encouraging the second category, but if the time is
too short that use will not grow).
jjb
Dave Townsend
I don't think there is any need for the second category, if developers
want to make builds available for people to test they should be copying
them somewhere else. I tend to agree though that 14 days is probably
plenty, 7 days should be adequate I think. I'm betting the majority of
uses of TryServer are to check builds work and test ok now, so optimise
for that.
John J. Barton
...
>> with 30 days (or more). I'm guessing: the try servers have two classes
>> of uses,
>> 1) "will this work on box other than the one I own?" 2days
>> 2) "try this cool feature I think it kinda works" 30 days.
>> After two days the first class is forgotten or stale anyway.
>>
>> (I'm interested in encouraging the second category, but if the time is
>> too short that use will not grow).
>> jjb
>
> I don't think there is any need for the second category, if developers
> want to make builds available for people to test they should be copying
> them somewhere else. I tend to agree though that 14 days is probably
I guess that many developers don't have access to a server or that
access is very painful. Convincing a developer to put a special build up
on a try server is already difficult. Adding that they have to wait for
the build, then find a server and copy it over means this option is
essentially gone. We really want the opposite, to have the early trials
very easy so improvements and problems can be quickly reved.
jjb
Blair McBride (Unfocused)
server builds. But is there any infrastructure for keeping specific
builds indefinitely (until manually removed)?
- Blair
Mike Shaver
<bmcb...@mozilla.com> wrote:
> I'm not opposed to reducing the TTL to 14 days for the majority of try
> server builds. But is there any infrastructure for keeping specific builds
> indefinitely (until manually removed)?
Worst case, you could probably file a ticket to get it copied to
stage. If that stops scaling, the people who hurt will be exactly the
people best able to write tools to automate or assist that process, so
I suspect it wouldn't be a long-term problem. :)
Mike
Vladimir Vukicevic
I realize this would complicate things, but having the 30 day builds
there can be useful... would it be possible to add a checkbox to let
users pick 30d or 14d (or even 1d) for the build TTL when they submit
the patch? It could default to 1d even, to reduce the demands even more.
- Vlad
Ehsan Akhgari
Whatever solution we come up with here should also work for the hg
interface to the try server. Many people (me included) usually submit
try server patches by pushing to the try hg repository, so selecting a
retention period option may not be possible.
--
Ehsan
<http://ehsanakhgari.org/>
Mike Shaver
> On Sat, Apr 4, 2009 at 9:03 AM, Vladimir Vukicevic <vlad...@pobox.com> wrote:
> interface to the try server. Many people (me included) usually submit
> try server patches by pushing to the try hg repository, so selecting a
> retention period option may not be possible.
hg push ssh://hg.mozilla.org/try-14d
hg push ssh://hg.mozilla.org/try-30d
hg push ssh://hg.mozilla.org/try-1d (== /try)
Mike
John O'Duinn
> On Thu, Apr 2, 2009 at 6:54 AM, Blair McBride (Unfocused)
> <bmcb...@mozilla.com> wrote:
>> server builds. But is there any infrastructure for keeping specific builds
>> indefinitely (until manually removed)?
>
> stage. If that stops scaling, the people who hurt will be exactly the
> people best able to write tools to automate or assist that process, so
> I suspect it wouldn't be a long-term problem. :)
>
> Mike
hi;
For now, we're going to reduce the time from 30 days to 14 days. Others
have suggested 2 or 7 days, but lets start with 14 for now. We can
revisit later, and see if we can reduce further. Please follow along in
bug#485443.
If you need a specific try build to be preserved for longer then 14
days, please file a bug with mozilla.org/ReleaseEngineering, telling us
where you want your try build copied to. Be sure to specify exactly when
you did the try build, so we have enough time to move the build before
the 14 days are up.
I know its suboptimal to manually file a bug for this, and have us
manually copy files out like this. However, it feels rare enough that I
think we can all live with it for now. Also reducing TTL *now* will get
us out of our current current space situation, while we figure out what
if anything might be needed for longer-living try builds.
tc
John.
Nick Thomas
John J. Barton wrote:
> I guess that many developers don't have access to a server or that
> access is very painful.
I don't agree with that assertion. The majority of the people who can
use the try server can get an account on people.mozilla.org and transfer
builds there. As Shaver has suggested, we can create a space on ftp.m.o
for longer term hosting if people will need that instead.
Mike Shaver wrote:
> hg push ssh://hg.mozilla.org/try-14d
> hg push ssh://hg.mozilla.org/try-30d
> hg push ssh://hg.mozilla.org/try-1d (== /try)
I doubt this level of complexity is going to be worthwhile. If I was a
starting a build I'd probably play it safe and chose the 30 day option
just about every time. Mostly because you'd know if you want to keep
something after the build completes (based on test results etc) rather
than before.
If we have the mechanisms above for saving builds for longer periods
then it sounds like we should go ahead with the 14 day expiry.
-Nick
Peter Weilbacher
> Responding to various comments ...
>
> John J. Barton wrote:
> > I guess that many developers don't have access to a server or that
> > access is very painful.
>
> I don't agree with that assertion. The majority of the people who can
> use the try server can get an account on people.mozilla.org and transfer
> builds there.
How? Would that not still entail to first download it from try and then
upload it somewhere else (people or elsewhere)? For people outside Mozilla
Hq that will be painful. Unless there is some kind of shell access to try
that would let me directly copy it around.
> As Shaver has suggested, we can create a space on ftp.m.o
> for longer term hosting if people will need that instead.
>
> Mike Shaver wrote:
> > hg push ssh://hg.mozilla.org/try-14d
> > hg push ssh://hg.mozilla.org/try-30d
> > hg push ssh://hg.mozilla.org/try-1d (== /try)
>
> I doubt this level of complexity is going to be worthwhile. If I was a
> starting a build I'd probably play it safe and chose the 30 day option
> just about every time. Mostly because you'd know if you want to keep
> something after the build completes (based on test results etc) rather
> than before.
I don't agree. I was asked several times to put a more complex OS/2 patch
through the try server with the single reason to make sure that it builds
on the main platforms. I saw the same happen for quite a few other patches
for unusual configurations. For those I would surely not pick the 30 day
option.
Nick Thomas
This was put in place on Thu April 9th.