[Beaker-devel] First draft of reservations design proposal

Raymond Mancy rmancy at redhat.com
Mon Sep 30 04:28:51 UTC 2013



----- Original Message -----
> From: "Nick Coghlan" <ncoghlan at redhat.com>
> To: beaker-devel at lists.fedorahosted.org
> Sent: Monday, September 30, 2013 1:30:31 PM
> Subject: Re: [Beaker-devel] First draft of reservations design proposal
> 
> On 09/30/2013 11:53 AM, Dan Callaghan wrote:
> > 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)
> 
> I think I like where this is going, as having the watchdog and the
> reservation separate has always seemed a little odd to me. I'll base the
> next draft on this approach and see where it gets us.
> 

The watchdog has always expected a recipe and the reservation has only ever expected
a system. So it only really makes sense to combine the two when every reservation has an
(optional)expiry time, which will be now :-)

> 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