On 09/26/2013 11:56 PM, Nick Coghlan wrote:
On 09/27/2013 12:00 PM, Raymond Mancy wrote:
>> This proposal supplements the current timed system reservation mechanism
>> with a new mechanism that is independent of the lab controller's external
>> watchdog timer. This new reservation timer is then used to offer time
>> limited manual reservations and automatic reservation of systems when
>> using an alternative harness or after a recipe is aborted.
>>
> Any reason why we can't use the current watchdog with an alternative harness ?
We can and do. The problem for alternative harnesses is with relying on
the "reservesys" task to handle reserving the system at the end of the
recipe, since not all alternative harnesses will support running that.
I started writing this thinking I didn't want to rely on a "special"
task to reserve a system. But the more I think about it I don't see a
better solution. One thing that would change is the reserve task should
simply sleep forever. Then if return2beaker is run it will kill the
sleep and allow the harness to move onto the next task. This allows you
to interleave reservesys tasks between other tasks/operations. The main
reason the current harness can't do this perpetual sleep is because it
has no way to update the local watchdog if the user wants to extend the
reservation. But the restraint harness I'm working on does allow you to
extend the current localwatchdog and externalwatchdog.
Thoughts?
>> Harness independent time limited reservations
>> ---------------------------------------------
>>
>> A new "expiry date" attribute will be added to reservation records.
>>
> I think we still want to be using one place to be the authoritative source of when a
system has to be returned
> (i.e the external watchdog or some modified schema of it), otherwise it will just add
complication.
>
> I'm imagining something where the server gets an abort/fail/warn/pass and then
checks the watchdog to
> see if it has any of these flags set, and will then update the watchdog time
accordingly.
If you can see a reasonable way to tie manual reservations into the
existing watchdog mechanism, then yes, that would be a good approach.
It wasn't immediately obvious to me how to do that, though, which is why
I went with this alternative for the initial design.
Also, see below regarding hard time limits.
>> Deferred features
>> -----------------
>>
> How about the ability of setting hard time limits on systems? If we are going to
redesign how we
> track the reservation time of systems, perhaps this is something we should think
about as well?
A potentially interesting alternative would be to use the existing
watchdog timers to manage the user-defined duration of reservations,
while leaving the expiry date for the reservation under the control of
system owners.
So starting the watchdog for manual reservations is definitely an
alternative worth pursuing - I'll take a closer look at the code to see
if I can figure out how to make that work.
Cheers,
Nick.