It may not be that simple to just use api name alias. For example, we currently have listS3sCmd, with new image store plugin framework, we introduced a new API "listImageStoresCmd" to cover image stores from various providers, not only S3. We also introduced a new response ImageStoreResponse for this new listImageStoreCmd api. So you are suggesting to use the following naming alias to direct old apis to the new apis, right?
@APICommand(name = "listImageStores, listS3s, listSwift", .. But there are two issues here: 1. Previous listS3sCmd api is corresponding to new API listImageStores&provider=S3, so this will not be a simple redirect. 2. Previous listS3sCmd response is S3Response, which is different from new ImageStoreResponse, although its information can be found in new ImageStoreResponse. Will this break back compatibility as well? Thanks -min On 4/9/13 10:14 AM, "Chiradeep Vittal" <chiradeep.vit...@citrix.com> wrote: >We can have alias for an existing API. See the other ML discussion. > >On 4/9/13 9:27 AM, "Min Chen" <min.c...@citrix.com> wrote: > >>Yes, I will include more api change details in FS in next few days. >>According to Chiradeep, it seems that we cannot simply deprecate old API >>in 4.2, Edison and I will discuss this and update FS with details on how >>to handle these old APIs. >> >>Thanks >>-min >> >>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+Backup+Ob >>>j >>>e >>>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 >>> >>> >> >
