[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