[Beaker-devel] First draft of reservations design proposal

Raymond Mancy rmancy at redhat.com
Fri Sep 27 05:22:07 UTC 2013



----- Original Message -----
> From: "Nick Coghlan" <ncoghlan at redhat.com>
> To: beaker-devel at 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 at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/beaker-devel
> 


More information about the Beaker-devel mailing list