On Wed, Jun 19, 2013 at 07:11:19PM +0000, Edison Su wrote: > > > > -----Original Message----- > > From: John Burwell [mailto:jburw...@basho.com] > > Sent: Wednesday, June 19, 2013 11:43 AM > > To: Edison Su > > Cc: dev@cloudstack.apache.org > > Subject: Re: NFS Cache storage query > > > > Edison, > > > > Based on the stance you have outlined, the usage of NFS in the object_store > > branch and 4.1 are not comparable. In 4.1, NFS is the store of record for > > data. > > Therefore, presence of the file in the NFS volume indicates that the data is > > permanently stored. However, in object_store, presence in NFS in the > > object_store branch means that the data may be awaiting permanent stage > > (dependent on the type of pending transfer operation). As such, I think we > > will need to provide insurance that in-flight operations are completed > > before > > a staging/temporary area is destroyed. Another option I can see is to > > change > > the way these staging/temporary areas are associated with zones. If we > > approached them as standalone entities that are attached or detached from > > a zone, we could define the detach operation as only disassociation from a > > zone without impacting in-flight operations. This solution would allow > > zones > > to be deleted without impacting in-flight operations. > > The interface is there: > https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blob;f=engine/api/src/org/apache/cloudstack/engine/subsystem/api/storage/DataStoreLifeCycle.java;h=1e893db6bb5b1dbae0142e8a26019ae34d44320a;hb=refs/heads/object_store > Admin should be able to put the data store into maintenance mode, and then > delete it, but the implementation is not there yet for both NFS secondary > storage and staging area. > For NFS, S3 secondary storage, we should at least implement > maintenance/cancelMaintain in 4.2 > For NFS staging area, we should at least implement maintenance/cancelMaintain > in 4.2, the delete method in 4.3. > How do you think?
Seems reasonable to me.
