From: Ian Main imain@redhat.com Date: Mon, 14 Mar 2011 16:46:55 -0400
On Mon, Mar 14, 2011 at 03:57:40PM -0400, John R. Dunning wrote: > From: Ian Main imain@redhat.com > Date: Mon, 14 Mar 2011 15:50:07 -0400
[snip]
> > Actually I was just looking through the code and AFAICT this is only > supported for Xen based VMs, not KVM. It would be easy enough to add to > condor though.. but then we are getting into needing a modified condor > again. Perhaps this line of development would be useful to upstream > though? > > I would expect that it would be useful upstream. But whether or not > that's the case, it's a pretty hard requirement for our usage of this > stuff.
OK, I stand corrected, you can in fact invent whatever XML you want to hand to virsh via whatever params you want in the job. So, we are golden on that front.
Ok.
So to recap:
1. We have a scheme for using condor to handle the resource allocation, ie when a request comes in, decide where to place it, and cause an instance to be launched.
2. We know how to make that scheme interact with the process of copying images around when needed, so that the iwhd will be able to provision images into it once, and let the "backend" deal with horsing things around as needed at launch time.
3. We believe we can arrange to pass a small snippet of config data in at launch time, to point a booting instance at some source of further config.
4. [I assert] that we have established the need for some kind of config server to exist at launch time. So the strawman implementation of 3 is to point the instance at the config server.
5. Assuming I'm correct about 4, that server can also communicate the IP address of the booting instance back to the mother ship (conductor). So there's no need to build any other scheme for managing IP addresses.
6. We understand what's needed to build a DC API interface layer to the condor instance referenced in 1. Michal is all over that.
7. We will need to work out the admin details of standing up the stateful server piece, presumably including the condor instance, the config server, and the interface piece. I believe David has volunteered to take a look at this piece.
So I think that's all the functional pieces we need.
TBD:
What do we document about standing up the actual servers which are running the VMs?
Do we need to do anything about mac address management? Is that part of 1?
What else have I forgot to mention?
If this is all about right, is it time to divvy up tasks and talk about timeframes and stuff?