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@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/beaker-devel