----- Original Message -----
From: "Nick Coghlan" <ncoghlan(a)redhat.com>
To: beaker-devel(a)lists.fedorahosted.org
Sent: Friday, September 27, 2013 1:56:59 PM
Subject: Re: [Beaker-devel] First draft of reservations design proposal
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.
Right, so for alternative harnesses it is s not necessarily the watchdog that needs
fixing, but how it gets
updated.
>> 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.
Currently the watchdog uses recipe and system to track resources. The recipe is closely
coupled to results, logs etc etc, so I don't think that we want to try and shoe horn
that to work
with a Manual reservation.
Maybe instead what we need is a lower level identifier, which is completely agnostic to
schedulers,
results, logs etc, but instead simply identified a checked out 'resource' (i.e
like a physical or
virtual resource, not like a RecipeResource). The watchdog now monitors this lower level,
so whenever
you extend or want to check the time, the recipe is not used directly.
I'm thinking of something not completely dissimilar to our current SystemResource etc,
but currently that
paradigm rests on the idea that every *Resource runs on a recipe.
Also thinking a bit further into Loans, perhaps what we really want is a TimedResource
base of which Loan could also
inherit from.
Anyway, I'm sure there are more than one ways to skin it, but having a common time
based tracker that is below that
of recipe would be crucial to avoid multiple tracking systems for multiple types of
things.
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.
Yes that makes sense I think.
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.
--
Nick Coghlan
Red Hat Infrastructure Engineering & Development, Brisbane
Testing Solutions Team Lead
Beaker Development Lead (
http://beaker-project.org/)
_______________________________________________
Beaker-devel mailing list
Beaker-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/beaker-devel