[Beaker-devel] Adding resource management to beaker

Bill Peck bpeck at redhat.com
Tue Sep 3 18:03:38 UTC 2013


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 know there is a resource type for recipe but this doesn't seem like a 
good solution.  I did try an experiment where I created StorageX host in 
beaker with no power control and scheduled three recipesets like above.  
But this hack won't work because a watchdog with a NULL expire time is 
set and that means it will sit there forever.  Even if it did work, 
maybe if we created a dummy power type, we would still end up with an abort.

I don't think it would take much work to support this type of 
multi-host/resource requirement.

Right now we have the following model

Object Recipe, which has the following attributes: distro_tree, 
resource, rendered_kickstart, watchdog, systems, dyn_systems, tasks, 
dyn_tasks, tags, repos, rpms, logs, custom_packages, ks_appends
Object MachineRecipe which inherits from Recipe, and adds a guests 
attribute.
Object GuestRecipe which inherits from Recipe.

A ResourceRecipe object wouldn't need most of these attributes, probably 
just the following:
resource, systems, and dyn_systems.  (no watchdog, just return when 
recipeSet completes or aborts)

And resource currently maps to a RecipeResource which can be one of the 
following:
SystemResource
VirtResource
GuestResource

I think adding another Object here would make sense, but the term 
Resource is overused and its a little confusing right now.

If done correctly we could re-use the filtering code in needproperty, 
but I think the only things we could search on for resources would be 
the following: Name, lab_controller, and key_values?  (storing how these 
shared resources are connected would be another option I suppose, but 
maybe too complicated for a first implementation?)

I'm sure there are other things to consider, we could support setting up 
and tearing down shared resources (almost like a power on/off command).  
I want to be mindful of things like that but I don't want to be 
paralysed with what if's and never get anything done.

I know you guys have been working hard on the groups features and want 
to re-do the scheduler as well.  Maybe this would be something for after 
the scheduler re-write?  I don't see any mention of this on the roadmap 
[1] (although the roadmap is quite full already!).

In any event, I'm interested in hearing your ideas and feedback.

Thanks!

1 - http://beaker-project.org/dev/tech-roadmap.html


More information about the Beaker-devel mailing list