Edison, For 4.2, are we going to state that the object store is just a backup of NFS (i.e. the same as 4.1)?
Thanks, -John On Jun 19, 2013, at 1:58 PM, Edison Su <edison...@citrix.com> wrote: > > >> -----Original Message----- >> From: John Burwell [mailto:jburw...@basho.com] >> Sent: Wednesday, June 19, 2013 10:42 AM >> To: dev@cloudstack.apache.org >> Cc: Edison Su >> Subject: Re: NFS Cache storage query >> >> Chip, >> >> 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? > > The current mater branch, there is no such operation for secondary storage > yet, so does the object_store branch. > Maybe we can discuss/implement a better life cycle management of both nfs > secondary storage and staging area in collab next week. > >> >> Thanks, >> -John >> >> On Jun 19, 2013, at 1:26 PM, Chip Childers <chip.child...@sungard.com> >> 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 <chip.child...@sungard.com> >> 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? >>>> >>>> >
