On 12/19/2011 09:16 PM, Bill Peck wrote:
Hi Steve,
I'd like to discuss more on how we can best integrate Beaker with RHEVM.
RHEV or oVirt? RHEV 3.0 is almost available, oVirt's first release is
scheduled to end of Jan 2012
(
http://www.ovirt.org/wiki/Releases/First_Release ).
The advantage of oVirt over RHEV is that it'll have the Python CLI/SDK,
which is cooler than RHEV's REST interface. But personally I'd go with
the REST interface first. Conversion should be fairly easy later on.
Goals:
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 (Windows)
Windows is not that difficult to provision automatically, from my
experience. It's very configurable and scriptable. But you need the
environment set up (Windows RIS services, local Windows Update server,
etc.). I used to have that (all in VMs, btw!).
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 support 32bit as well, of course.
- Q: do you actually need 20GB of disks? If not really, you can use thin
provisioning, which will be quicker to provision. RAW would provide
better performance, though.
- 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?
You CAN rely on a match 'partially' available - a template may already
exist that matches your requirement. The 'partially' refers to the fact
you may not be able to execute a snapshot of that template due to lack
of resources.
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.
Yes, you should get failure message. Some messages are better than
others ;-/
I think you had some ideas on this and I'm hoping we can work through
them here. :-)
Alternatively, (and something we are looking for future versions to be
built in to the product) - have X number of systems ready for
re-provisioning.
For example, our internal continuous integration system has several VMs
which are always ready for re-install if needed, used as RHEVM servers.
There's a fixed number of them.
For phase 1, I'd start with that, see how it goes. Then we can add
dynamically provisioned systems.
Note that creating VMs should be merely a snapshot from an existing
template and then 'prepping' the VM (sysprep in Windows, something
similar in Linux).
That should be quick - take ~5 minutes, tops. If you are installing from
scratch it may take a bit more, similar to a physical system.
Y.
_______________________________________________
Beaker-devel mailing list
Beaker-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/beaker-devel