[Beaker-devel] Adding resource management to beaker

Nick Coghlan ncoghlan at redhat.com
Wed Sep 4 04:02:22 UTC 2013


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
*lot* of assumptions in needproperty that the thing being scheduled is a
computer).

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

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 :)

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