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