Hi Nick,
I never replied to you about this and got distracted by other issues.
This is becoming more important again, so I wanted to get the discussion
going again.
Comments inline...
On 09/04/2013 12:02 AM, Nick Coghlan wrote:
On 09/04/2013 04:03 AM, Bill Peck wrote:
> Hello Beaker,
>
> One of the jobs we run uses shared storage. For example:
>
> HostA with Driver1
> HostB with Driver2
> HostC with Driver3
>
> All connected to StorageX.
>
> We can't run the test on more than one host at a time since it would
> conflict.
>
> Being able to specify the following in the job xml is the goal:
>
> <recipeSet>
> <recipe/> <!-- Require HostA -->
> <resource/> <!-- Require StorageX -->
> </recipeSet>
> <recipeSet>
> <recipe/> <!-- Require HostB -->
> <resource/> <!-- Require StorageX -->
> </recipeSet>
> <recipeSet>
> <recipe/> <!-- Require HostC -->
> <resource/> <!-- Require StorageX -->
> </recipeSet>
I think there are some underlying assumptions that you need to unpack
before we (or at least I) can give you good feedback.
What is "resource" here? Is this just about scheduling access to opaque
entities that Beaker doesn't actually control in any way, we're just
doing the queue management to avoid multiple recipes trying to use them
at once? (I assume so, since external resources that can be shared can
just be specified in the parameters)
If so, allowing full needproperty filtering may be overkill (there are a
You say needproperty may be overkill but you confused me when describing
how external resources would work below.
*lot* of assumptions in needproperty that the thing being scheduled
is a
computer).
Don't we use the same needproperty logic for both system and distro?
It's either <distroRequires> or <hostRequires> seems logical to add
<resourceRequires>.
What may be more appropriate is to design an "External Resources"
mechanism that was just an opaque key/value store from Beaker's point of
view. The initial iteration might only allow a very limited set of
queryable attributes (say "kind" and "name", with those two serving
as a
unique key).
So then, in your case, you might do something like:
<recipeSet>
<recipe>
<!-- Require HostA -->
<external kind="Storage" name="StorageX"/> <!--
Require StorageX -->
Would I have to specify name? Would name have to be unique?
Would be
nice to keep the requirements abstract so I could select any storage
that is available if it fits the criteria.
<recipe/>
</recipeSet>
When defining an external resource, that definition would have a
"hostRequires" limiting where it can be used (e.g. for network
accessible resources, perhaps any system in the local lab, for hardwired
resources, an "<or/>" element listing the connected systems). If a
recipe has external resources listed, then Beaker would add the
hostRequires for the external dependency to that defined directly in the
recipe.
Wouldn't resources need to be assigned to a lab controller as well?
Such external resources would likely need some of the other properties
of systems, though, like owners and an access policy. Convenient that
we're decoupling access policies from system definitions in 0.15/16 :)
I agree
that we would want ACL's. especially for storage related resources.
Cheers,
Nick.