[Beaker-devel] First draft of reservations design proposal

Bill Peck bpeck at redhat.com
Mon Sep 30 14:12:46 UTC 2013


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



More information about the Beaker-devel mailing list