[Beaker-devel] First draft of reservations design proposal

Raymond Mancy rmancy at redhat.com
Fri Sep 27 13:49:35 UTC 2013



----- Original Message -----
> From: "Nick Coghlan" <ncoghlan at redhat.com>
> To: beaker-devel at lists.fedorahosted.org
> Sent: Friday, September 27, 2013 5:05:05 PM
> Subject: Re: [Beaker-devel] First draft of reservations design proposal
> 
> On 09/27/2013 03:22 PM, Raymond Mancy wrote:
> >> 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.
> 
> We already have the reservation table, so I wouldn't want to add *yet
> another* concept merely as a generalisation of "has a deadline". It may
> just be a matter of giving the watchdog a reference to the reservation
> in order to cope with the difference between the automated and manual cases.
> 

Yeah ok so the reservation table could probably be used.

> In fact, perhaps we could get rid of the "reservation type" field by
> giving the reservation a reference to the recipe as well? Then manual
> reservations would just be those where the recipe reference is NULL.

I'm not a great fan of having NULL infer a reservation type of X. It's not
really obvious, is prone to error and puts you in a bind if you come
up with another reservation type we want to represent.

Could we not change the base Resource class to not require a recipe_id,
then have ManualResource which has a corresponding reservation, and now in Watchdog
we could have a FK to the reservation (which is linked to the resource), 
rather than the recipe id.

Both manual and scheduled systems could then have their time limits managed in the same
place.
> (I
> suspect getting rid of the direct relationship between the recipe and
> the watchdog would be far too invasive a change, but making that a
> potentially triangular relationship and remembering which reservation
> went with which recipe could be worthwhile)
> 
> >> 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.
> 
> I suspect it will take some poking around in the code to decide on this
> one. I'll do some more of that before updating the design :)
> 
> 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