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(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
>>
>> 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.
Cheers,
Nick.
--
Nick Coghlan
Red Hat Infrastructure Engineering & Development, Brisbane
Testing Solutions Team Lead
Beaker Development Lead (
http://beaker-project.org/)