Excerpts from Yaniv Kaul's message of Tue Dec 20 17:00:54 +1000 2011:
On 12/19/2011 09:16 PM, Bill Peck wrote:
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!).
Our approach might depend on how much flexibility we want or require with each of these other operating systems. Automatic provisioning of Windows (without images) sounds easy enough, but we would need a sensible way to model the requirements for a job (for all variants of all the OSes we are going to support). If maintaining a handful of standard images isn't going to generate too much overhead, it would make this aspect simpler. (And there is the performance advantage, mentioned below.)
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.
If the recipe requires at least 20GB of disk, then yes, it should have a device with at least that amount of disk available because there's no telling what the job will do with it. Bill's example is for a job that might be submitted with something like:
<hostRequires> <memory op=">=" value="4000"/> <arch op="=" value="x86_64"/> <key_value key="DISKSPACE" op=">=" value="20000"/> </hostRequires>
Currently, we just search for all systems that match those requirements. But there's nothing to say this recipe couldn't run in a VM but we would need to first check whether RHEVM can provision such a guest, and if so, create a specific guest definition.
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.
So basically RHEVM will tell us "yes, this guest could be created, just not right now"?
Knowing whether we can provision that VM immediately is important because otherwise we can move onto the search for a "real" system that matches the requirements, i.e. we wouldn't want a job held up because it *could* be run via RHEV while there are idle baremetal boxes sitting in the lab. But at the same time, we don't want to poll RHEVM continually for all jobs sitting in the queue.
Could RHEVM notify Beaker of changes in available resources (such as when a guest is destroyed or created)? Maybe Beaker itself could track RHEV's available resources and just poll for changes at the start of each loop over the queued recipes, rather than repeatedly asking RHEVM whether it could provision each one?
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.
I'm not sure I follow -- do you mean as target/test hosts? That's more or less the approach we already take; we have quite a few "systems" available to be scheduled in Beaker that are virt guests with fixed memory and storage. So the whole goal here is dynamically provisioned systems in that sense.
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.
This speed-up is a good benefit, but I think first of all we really need to be able to install from scratch just like we currently do, by tweaking the kickstarts (and allowing users to submit custom kickstarts) so that we can run more recipes as-is.
Steven.