Hi Sangeetha,
See my answers inline.
Thanks
-min
On 4/9/13 2:48 PM, "Sangeetha Hariharan" <sangeetha.hariha...@citrix.com>
wrote:
>Can image stores from different providers (NFS,SWIFT,S3) coexist in the
>same deployment ?
>Is the scope for NFS always Zone-wide and SWIFT and S3 region-wide?
[Min] Currently this is our assumption: you can add multiple image stores
from the same provider, but we prevent you from adding multiple image
stores from different providers. For NFS image store providers, it is
always zone-wide. And For S3/Swift, it is always region-wide.
>
>There is an api for "enableImageStoreCmd" . Can multiple image stores be
>enabled at the same time?
>I don't see any api for disabling image store? What does it mean to
>disable an already enabled image store? Will all the resources like
>templates, iso and snapshot residing in this image store not be available
>to the users anymore?
[Min] On second thought, we decide to drop this api. addImageStore api
will automatically make the image store added active to be consistent with
current secondary storage behavior.
>
>
>deleteImageStoreCmd - Will we allow for deletion of an image store when
>it has resources like templates, iso and snapshots residing in it?
[Min] Deletion of an image store will check if it has resources like
template, snapshots, and volumes. If there are resources residing in it,
we will throw error.
>
>-Thanks
>Sangeetha
>
>-----Original Message-----
>From: Edison Su [mailto:edison...@citrix.com]
>Sent: Tuesday, April 09, 2013 2:01 PM
>To: dev@cloudstack.apache.org
>Subject: RE: [DIscuss]Storage image store plugin framework refactoring
>
>
>
>> -----Original Message-----
>> From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com]
>> Sent: Monday, April 08, 2013 11:33 PM
>> To: dev@cloudstack.apache.org
>> Subject: Re: [DIscuss]Storage image store plugin framework refactoring
>>
>> We can't deprecate APIs unless we are changing to 5.0 AFAIK the next
>> release in plan is 4.2
>For back compatibility, these APIs:
>addSecondaryStorageCmd,addS3Cmd,addSwiftCmd,listS3Cmd,listSwiftCmd, can
>still be wired to new code, so this APIs will still work, but we can mark
>them as deprecated in the API document.
>
>>
>> How does an upgrade from 4.0/4.1 to 4.2 work with this proposal?
>> - what happens to existing SSVMs?
>> - if there are multiple SSVMs?
>> - current cache-like deployments for S3 and Swift
>
>The existing deployment model will still work.
>There are following combinations currently supported by CloudStack:
>1. Only NFS as secondary storage. In the new framework, it's NFS as a
>backup storage.
>2. NFS + swift/S3. In the new framework, it's swift/s3 as backup storage,
>while, NFS as cache storage.
>So the upgrade code from pre-4.2 to 4.2 needs to handle above cases,
>migrate DB properly.
>
>>
>> The SSVM code also does duty for VMWare deployments to aid in data
>> movement.
>
>
>The existing SSVM will still work, it will be renamed to transportation
>VM in the code(maybe on the UI, it still be called SSVM). The main
>functionality of these VMs are to help transfer data from one place to
>another. As you said, Vmware deployment needs these VMs(as Vmware can't
>directly download template into primary storage), and old NFS based
>secondary storage deployment model needs them(data copy when cross zone).
>
>
>> How does this change?
>>
>> On 4/8/13 6:34 PM, "Sangeetha Hariharan"
>> <sangeetha.hariha...@citrix.com>
>> wrote:
>>
>> >Min,
>> >
>> >Could you also include the details of the API changes (new
>> >parameters) that will be proposed as part of this feature?
>> >Also it would be helpful if you list the request and response
>> >parameters for the new API calls.
>> >For all the API calls that are being deprecated , is there any
>> >specific error message that will be returned?
>> >
>> >-Thanks
>> >Sangeetha
>> >
>> >-----Original Message-----
>> >From: Min Chen [mailto:min.c...@citrix.com]
>> >Sent: Monday, April 08, 2013 4:45 PM
>> >To: dev@cloudstack.apache.org
>> >Subject: [DIscuss]Storage image store plugin framework refactoring
>> >
>> >Hi All,
>> >
>> >Currently CloudStack does not offer a flexible pluggable framework
>> >for users to easily integrate and configure any 3rd-party object
>> >stores for such backup services as registering templates, taking
>>snapshots, etc.
>> >Along with Edison's recent refactored storage subsystem 2.0 that
>> >mainly refactored current CloudStack primary storage implementation,
>> >we are proposing to develop a storage backup object store plugin
>> >framework to allow CloudStack to systematically manage and configure
>> >various types of backup data stores from different vendors, like NFS,
>>S3, Swift, etc.
>> >With this new plugin framework, we would like to achieve following
>> >functionalities:
>> >1. Support different object store providers in a uniform and
>> >pluggable fashion.
>> >2. Enable region wide object backup using S3-like object store.
>> >3. Provide pluggable data motion strategies to handle data transfer
>> >from one data store to another data store.
>> >4. Provide a scalable cache storage framework while moving data
>> >between primary storage and backup storage for certain hypervisor
>>needs.
>> >5. Support flexible combinations of primary storage, secondary
>> >storage and hypervisors, such as (NFS, NFS, Xen), (NF3, S3, Vmware),
>> >(ISCSI, Swift, KVM), ...., etc.
>> >The proposed ImageStore plugin framework architecture is detailed in
>> >our FS here:
>> >https://cwiki.apache.org/confluence/display/CLOUDSTACK/Storage+Backu
>> p+O
>> >bje
>> >ct+Store+Plugin+Framework.
>> >The JIRA ticket to track this feature is:
>> >https://issues.apache.org/jira/browse/CLOUDSTACK-1975. The work is
>> >currently carried out in feature branch "object_store".
>> >Please let me know your comments and suggestions.
>> >
>> >Thanks
>> >-min
>> >
>> >
>
