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