Reducing TTL for try server builds

0 views
Skip to first unread message

Nick Thomas

unread,
Mar 31, 2009, 11:02:33 PM3/31/09
to
We're proposing an adjustment to the time we keep the builds produced by
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

unread,
Apr 1, 2009, 12:05:32 AM4/1/09
to

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

unread,
Apr 1, 2009, 3:09:30 AM4/1/09
to

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

unread,
Apr 1, 2009, 11:44:22 AM4/1/09
to
Dave Townsend wrote:
...

>> 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)

unread,
Apr 2, 2009, 6:54:39 AM4/2/09
to
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)?

- Blair

Mike Shaver

unread,
Apr 2, 2009, 6:58:14 AM4/2/09
to Blair McBride (Unfocused), dev-b...@lists.mozilla.org
On Thu, Apr 2, 2009 at 6:54 AM, Blair McBride (Unfocused)
<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

unread,
Apr 4, 2009, 1:33:33 AM4/4/09
to Nick Thomas

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

unread,
Apr 4, 2009, 6:20:40 AM4/4/09
to Vladimir Vukicevic, dev-b...@lists.mozilla.org

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

unread,
Apr 4, 2009, 8:51:50 AM4/4/09
to Ehsan Akhgari, dev-b...@lists.mozilla.org, Vladimir Vukicevic
On Sat, Apr 4, 2009 at 6:20 AM, Ehsan Akhgari <ehsan....@gmail.com> wrote:
> On Sat, Apr 4, 2009 at 9:03 AM, Vladimir Vukicevic <vlad...@pobox.com> wrote:
> 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.

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

unread,
Apr 6, 2009, 5:59:31 PM4/6/09
to Mike Shaver, Blair McBride (Unfocused), dev-b...@lists.mozilla.org, vlad...@pobox.com
Mike Shaver wrote:
> On Thu, Apr 2, 2009 at 6:54 AM, Blair McBride (Unfocused)
> <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

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

unread,
Apr 6, 2009, 6:10:06 PM4/6/09
to
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. 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

unread,
Apr 7, 2009, 3:13:29 PM4/7/09
to
On 07.04.09 00:10, Nick Thomas wrote:
> 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

unread,
Apr 13, 2009, 4:10:39 PM4/13/09
to

This was put in place on Thu April 9th.

Reply all
Reply to author
Forward
0 new messages