[Beaker-devel] Adding resource management to beaker

Bill Peck bpeck at redhat.com
Tue Oct 21 13:16:01 UTC 2014


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



More information about the Beaker-devel mailing list