Cloudstack has a native api which is not a standard (only occi and cimi are ).
Recognizing early that aws ec2 is the de facto std we provide a mapping between ec2/ebs and our native api. The aim is to be fully compliant so that ec2 tools can be used transparently against a cloudstack cloud running the aws mapping (separate package to install on mgt server). Its probably not fully compliant so be warned. -Sebastien On 14 Oct 2013, at 20:25, "La Motta, David" <david.lamo...@netapp.com> wrote: > http://www.servicemesh.com/cloud-it-resources/cloud-strategy-transform-it-b > log/blog/apache-cloudstack-aws-for-every-man/ > > > Forgot the link! Sorry. > > > > On 10/14/13 2:14 PM, "La Motta, David" <david.lamo...@netapp.com> wrote: > >> Hello, folks. In reading this article (), I found this: >> >> "Interestingly, Apache CloudStack will follow a dual-API strategy. First, >> the project will maintain compatibility with the familiar AWS API, which >> allows users to leverage tool sets built to work with AWS. Love it or hate >> it, the AWS API is rapidly becoming the lingua franca of the cloud world. >> The AWS API has limitations, however, and so the Apache CloudStack project >> will also expose advanced functionality that is not covered by the AWS API >> through a parallel CloudStack API. Users can choose whichever API is most >> convenient and even use both for different reasons at the same time." >> >> Šwhich is great. Is this still valid? How can I differentiate between >> one type of API or another? >> >> The question comes from the use case of having CloudStack on-premise, then >> later migrating to AWS, but keeping the same APIs. In other words, the >> use case is to make use of the AWS API flavor so migration from on-premise >> to Amazon is transparent. >> >> Could somebody shed some light in this department? >> >> Thanks! >> >> >> David La Motta >> Technical Marketing Engineer - Citrix Solutions | NetApp >> Direct: 1.919.476.5042 >> >
