I'd like to discuss more on how we can best integrate Beaker with RHEVM.
1 - Dynamically create systems based on the requirements from Beaker recipe.
- Attempt to schedule on RHEVM first.
2 - Quick provisioning by using pre-built images
3 - Provide images for operating systems that are difficult to automate
Implementing all of the goals at once may be too much. I'd rather see
us tackle 1 and then move on to 2 and then 3.
The big question is how do we do this efficiently? Do we want to be
able to support multiple RHEVM servers?
thinking out loud here, here is how we currently process a recipe.
- A new recipe comes in that requires an x86_64 system with 4 gigs of
ram and 20 gig of disk space on Distro X.
- We select all systems that could possibly match, even ones that are on
labs that don't have Distro X (it may show up later)
- If the recipe is a multi-host recipe we then remove bad choices, all
recipes need to run in one lab.
- We schedule the recipe when a join condition from the recipe matches 1
or more systems.
- Finally when all recipes in a multi-host recipe set are scheduled we
move all of them to Running and kick off pxe installs
Because we want to create the system dynamically we can't rely on sql to
alert us that a match is available. I'm concerned with scalability, I
don't think you remember this, but old rhts attempted to match every
queued recipe every time through the loop. It was horrendous! The more
queued recipes you had the longer it took to do one loop. The sql
method works wonderfully because we join on the system being available,
we never see recipes that can't be serviced. So my concern is how we
implement this with RHEVM without creating a bottle neck?
I'm also wondering if RHEVM will be able to tell us the reason for not
being able to create a host. For example, when we ask to create a 32
gig system and RHEVM replies that it can't, is it because it doesn't
currently have enough ram because other hosts are running or is it
because the RHEVH box only has 16 gig ram it will never be able to
satisfy it. And if no one can satisfy it we should abort it.
I think you had some ideas on this and I'm hoping we can work through
them here. :-)