On 02/24/2011 05:12 PM, Perry Myers wrote:
> STATELESS CLOUD
> ---------------
>
> The way that some providers (such as rhevm and vmware) launch instances
> now are not what we need. Cloud launch must start an instance in
> such a way that it can perform multiple launches from the same image.
> To support that what really needs to happen is that prior to launch the
> image needs to be either cloned or snapshotted.
>
> Below are a couple of ways we thought of to do this:
>
> - Deltacloud API provider driver start call must clone disk on startup
> if the provider does not already do that.
> - On destroy, API must clean up cloned disk image if the provider does
> not already do it.
> - On shutdown, the API leaves the disk alone.
Couldn't you just map an instance in Aeolus to a template image in RHEVM?
You have a aeolus instance image, you upload it to rhevm as an image
template and then from there you can instantiate the image multiple
times, each time rhevm will take care of copying the image for you
(behind the scenes) or maybe it uses COW to do effectively the same
thing. Probably worth discussing this with the rhev developers.
_______________________________________________
aeolus-devel mailing list
aeolus-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/aeolus-devel Yes, that's essentially
what we're talking about -- in reality, both of
the options described result in the same actions on the RHEV side --
mostly we're working through how to handle it on the API/Condor side
_if_ we have to tell RHEV explicitly that we need the copying done _per
instance_.
First, I'd like to pull apart the confusing terminology here. There's no
such thing as an "instance image" in Aeolus -- we have an "image" --
which is the reusable disk image (i.e. pristine/gold image that's copied
for each running instance, like an AMI in ec2), and there's an
"instance" -- which is a single running VM.
In ec2 we just upload the AMI, and when you start an instance, ec2
copies it _somewhere_ and attaches that copy to the running instance --
when it's destroyed, ec2 makes it go away. We need to make sure the
behavior works similarly with RHEV, VMWare, etc.
If a RHEV "image template" already does this -- i.e. if image factory
uploads an image to RHEV as an "image template" and then, each instance
start request gets copied for us by RHEV automatically (and deleted for
us automatically when we destroy the instance), then we don't need
anything further from RHEV here -- that's exactly what we want.
What we must avoid at all costs is for an "image" uploaded from Aeolus
to get attached directly to a launched instance such that any attempt to
launch additional instances with the same image might fail (since
they're not being copied/snapshotted).
My understanding is that for VMWare, at least, this would be an issue
and that we need to handle the copy/snapshot and delete-upon-destroy
bits ourselves -- either in the API driver _or_ via the more convoluted
second option Chris outlined where we'd have to query the driver as to
whether the copy is needed and make 2 API calls, etc.