cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chiradeep Vittal <>
Subject Re: [DIscuss]Storage image store plugin framework refactoring
Date Tue, 09 Apr 2013 06:33:13 GMT
We can't deprecate APIs unless we are changing to 5.0
AFAIK the next release in plan is 4.2

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 SSVM code also does duty for VMWare deployments to aid in data
How does this change?

On 4/8/13 6:34 PM, "Sangeetha Hariharan" <>

>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?
>-----Original Message-----
>From: Min Chen []
>Sent: Monday, April 08, 2013 4:45 PM
>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
>1. Support different object store providers in a uniform and pluggable
>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: 
>The JIRA ticket to track this feature is:
> The work is
>currently carried out in feature branch  "object_store".
>Please let me know your comments and suggestions.

View raw message