----- Original Message -----
From: "Nick Coghlan" <ncoghlan(a)redhat.com>
To: beaker-devel(a)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(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/beaker-devel