deltacloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Lutterkort <>
Subject Re: Stateful Vs Stateless Instances Findings
Date Fri, 25 Feb 2011 00:10:42 GMT
On Thu, 2011-02-24 at 11:23 -0500, Ian Main wrote:
> 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.

We can't do this for a number of reasons:
      * the choice whether to clean up the cloned disk or not on destroy
        seems to involve state that the server would need to keep
      * failure of the instance start (e.g., because the Deltacloud
        server crashed) after a successful disk clone will leave the
        backend cloud in a state that is at least unexpected for the
        client. Since the Deltacloud server is stateless, it's not clear
        that the client would have any chance to ever clean up the
        cloned disk

> 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.

This seems the way to go for me; of course, what I said above
notwithstanding, client libraries are free to provide convenience calls
to make all this one seamless operation (assuming they are careful to
keep enough state so they can clean up when they crash at inopportune

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

If you're happy with going through door #2, I'll add tasks for this to
our backlog.

> ------------------------
> 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.

Agreed - there's a need to clean up the Deltacloud terminology in that


View raw message