[Beaker-devel] First draft of reservations design proposal

Nick Coghlan ncoghlan at redhat.com
Mon Sep 30 03:30:31 UTC 2013


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.

Cheers,
Nick.

-- 
Nick Coghlan
Red Hat Infrastructure Engineering & Development, Brisbane

Testing Solutions Team Lead
Beaker Development Lead (http://beaker-project.org/)


More information about the Beaker-devel mailing list