incubator-deltacloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Main <im...@redhat.com>
Subject Stateful Vs Stateless Instances Findings
Date Thu, 24 Feb 2011 16:23:07 GMT

We had a meeting this morning and we managed to hash some things out on
this subject.  Here is the result.  I am posting this to both
aeolus-devel and deltacloud-devel as it impacts both.


Stateful vs Stateless instances and the cloud
---------------------------------------------

In an effort to support private cloud, we had to sort out what to do about
'stateful' instances.  We're defining a stateful instance as one where
the image for the instance does not get destroyed when the instance is
stopped and it is possible to restart it with the same state.

Also, the model that Aeolus Conductor is using regarding images is the
same as ec2, where a given image can be used to launch as many instances
as needed.  This is not the same as the model used by many private cloud
providers where an image is used directly by a instance/VM and it is
not possible for it to be used by multiple running instances.

We want to tackle these questions in two different phases.  Stateless
cloud on supported providers is presently the most important requirement,
but we will need both soon.

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.

OR

- Deltacloud API provides instrospection into the driver and specifies
whether or not an instance start will clone the disk for us.
- It also needs to specify if the storage needs to be destroyed on
instance shutdown (some clouds do, some don't).
- Deltacloud API provides APIs for performing the clone and then cleanup
of cloned images.
- It is then up to the client to perform the right sequence of actions
to get the desired behavior.

Either of these will work and allow us to make the Conductor model
consistent with existing public cloud providers.


STATEFUL CLOUD INSTANCES
------------------------

Stateful instances have the ability to be stopped without destroying the
disk image and then resumed from the same state.  In order to support
this we need:

Condor:

- Condor must have "suspend"/stop/restart support.
- Image must be built to target stateful - we need a toggle at image
build time and at launch time.

Deltacloud API:

- Deltacloud API must support stop that does not cleanup disk image but
only if available.
- Introspection as to whether or not a stop is valid.  Currently
stop/destroy is the same op on ec2, but 'stop' should be invalid.  Stop is
only valid for stateful instances.  Destroy cleans up disk image.  This is
to act as introspection as to whether the instance is stateful or not.
This may not be needed depending on how we support disk clone/cleanup as
defined above.

Conductor: 

- If an instance on a stateful-only cloud is designated stateless, we must
track that extra condition in the conductor (because stateful/stateless
will act the same).  This lets us know if we need to clean up disk
images etc.
- We could provide a 'stateful/stateless' toggle at launch time that
warned the user there is no match and they must build a stateful instance
for it to work.


Thanks!

    Ian



Mime
View raw message