See my comments inline.

-min

On 4/16/13 11:41 PM, "Sanjeev Neelarapu" <sanjeev.neelar...@citrix.com>
wrote:

>Hi,
>
>Few more review comments:
>1.In a fresh installed environment will SSVM continue to be there? If yes
>will it be auto launched or admin should launch it?
[Min] ssvm will still be there and auto-launched as before.
>2.How do we seed system vm templates in case of object storage?
[Min] We will trigger system vm template download while adding an S3
object storage into cloudstack. The download is happening through MS host.
>3.Is there any difference in seeding system vm templates with NFS storage
>compared to what we do as of today?
[Min] We are not planning to change system vm templates seeding with NFS
storage at this point, still assume that you have pre-seeded system vm
template on NFS.
>4.In upgraded environment, can we have both NFS and object storage? If
>not what is the procedure to migrate from nfs to object storage ?
[Min] In our FS, we have made an assumption that "you can add multiple
image stores from the same provider, but we prevent you from adding
multiple image
stores from different providers." This implied that we cannot have both
NFS and S3 co-existing for this release. You raised a very good point,
honestly I don't have an answer at this point. Edison, any thoughts on
this?
>
>Thanks,
>Sanjeev
>
>-----Original Message-----
>From: Min Chen [mailto:min.c...@citrix.com]
>Sent: Wednesday, April 10, 2013 3:23 AM
>To: dev@cloudstack.apache.org
>Subject: Re: [DIscuss]Storage image store plugin framework refactoring
>
>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
>>> >
>>> >
>>
>

Reply via email to