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!
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.
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.
beaker-devel@lists.fedorahosted.org