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.
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
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/)