[Beaker-devel] First draft of reservations design proposal

Dan Callaghan dcallagh at redhat.com
Mon Sep 30 01:53:58 UTC 2013


Excerpts from Raymond Mancy's message of 2013-09-27 15:22:07 +1000:
> ----- 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
> > 
> > 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.

My suggestion would be:

* drop watchdog table
* store "expiry time" on reservation table
    - for recipes, this is set by the scheduler, and extended by the 
      existing "extend watchdog" mechanisms for the harness
    - for manual reservations, the person reserving can optionally 
      specify an expiry time when taking the system
* also store "expiry time" on loans (no polymorphism please!)
    - when granting a loan, an expiry time can optionally be specified
* new thread/whatever in beakerd to look for expired reservations and 
  loans
* beaker-watchdog no longer manages expiry times, though the daemon 
  remains purely for watching console logs (eventually this 
  responsibility should be rolled into the theoretical 
  beaker-lab-controller daemon)

-- 
Dan Callaghan <dcallagh at redhat.com>
Software Engineer, Infrastructure Engineering and Development
Red Hat, Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <https://lists.fedorahosted.org/pipermail/beaker-devel/attachments/20130930/878a4b1c/attachment.sig>


More information about the Beaker-devel mailing list