On 15.5.2014 22:56, Andrew Dunstan wrote:
>
> On 05/15/2014 04:30 PM, Stefan Kaltenbrunner wrote:
>
>> well I'm not sure about about "misconfigured" but both my personal
>> buildfarm members and pginfra run ones (like gaibasaurus) got errors
>> complaining about "snapshot too old" in the past for long running tests
>> so I'm not sure it is really a "we never had machine with runs that
>> long". So maybe we should not reject those submissions at submission
>> time but rather mark them clearly on the dashboard and leave the final
>> interpretation to a human...
>>
>
> That's a LOT harder and more work to arrange. Frankly, there are more
> important things to do.
>
> I would like to know the circumstances of these very long runs. I drive
> some of my VMs pretty hard on pretty modest hardware, and they don't
> come close to running 24 hours.
>
> The current behaviour goes back to this commit from December 2011:
>
> commit a8b5049e64f9cb08f8e165d0737139dab74e3bce
> Author: Andrew Dunstan <andrew@dunslane.net>
> Date: Wed Dec 14 14:38:44 2011 -0800
>
> Use git snapshot instead of fixed 10 day timeout.
>
> The sanity checks made sure that an animal wasn't submitting a
> snapshot that was too old. But sometimes an old branch doesn't
> get any changes for more than 10 days. So accept a snapshot that
> is not more than 1 day older than the last known snapshot. Per
> complaint from Stefan.
>
>
> I'm prepared to increase the sanity check time if there is a serious
> demand for it, but I'd like to know what to increase it to.
I doubt there's no "one size fits all" limit. If the machines running
"recursive clobber" tests need tens of days to complete the tests. then
that limit is pretty useless to most regular animals.
So what about keeping the current value for most animals, but allowing
an override for some selected ones? I'd expect this to be much simpler
to implement, and it shouldn't require any human intervention.
Tomas