cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Burwell <>
Subject Re: NFS Cache storage query
Date Wed, 19 Jun 2013 17:41:55 GMT

Your concern had not occurred to me -- making me realize that either destroy or a zone attach/detach
operation for the staging/temporary area mechanism in 4.2.  Thinking through it, there are
two types of operations occurring with the staging/temporary area.  The first is data being
pulled from the object store to support some activity (e.g. copying a template down to create
a VM).  From a data integrity perspective, it is safe to kill these operations since the data
has already been persisted to the object store.  The second is data being pushed to the object
store which are much more problematic.  Of particular concern would be snapshots that are
in the staging/temporary area, but not yet transferred to the object store.  

Edison/Min: Does the current implementation provide a destroy or attach/detach behavior? 
If so, how are in-flight operations handled to ensure there is no data loss?


On Jun 19, 2013, at 1:26 PM, Chip Childers <> wrote:

> On Wed, Jun 19, 2013 at 01:23:47PM -0400, John Burwell wrote:
>> Chip,
>> Good catch.  Yes, we need definitely need a create staging/temporary area API call.
 However, destroy is a bit more complicated due in-flight operations.  Given the complexities
and time pressures, I recommend supporting only create in 4.2, and addressing delete in 4.3.
 Does that make sense?
> If the existence of the staging datastore blocks the deleting of a
> zone, or any other entity, then that doesn't work for me.
> I'd rather give an operator the ability to decide how to best ensure
> that in-flight operations are halted (i.e.: block users from the
> environment or something else), than not give them a way to change their
> configuration.
>> Thanks,
>> -John 
>> On Jun 19, 2013, at 1:11 PM, Chip Childers <> wrote:
>>> On Wed, Jun 19, 2013 at 01:07:29PM -0400, John Burwell wrote:
>>>> Nitin,
>>>> If we provide any APIs for the staging/temporary area, they must be read-only.
 Allowing any external manipulation of its content could cause break in-flight transfers or
cause data loss.  I think we should consider the following APIs:
>>>> List contents including name, reference count, and size
>>>> Summary statistics for a staging area including consumed/available/total
space and timestamp of the last garbage collection operation
>>>> Force garbage collection/cleanup operation
>>>> I think we should these are new API calls specific to the staging/temporary
area mechanism rather than trying to overload existing API calls.
>>>> Thanks,
>>>> -John
>>> What about creating / destroying them?

View raw message