[openstack-dev] Discussing Amazon API compatibility [Nova][Swift]

Joshua Harlow harlowja at yahoo-inc.com
Thu Jul 25 03:13:33 UTC 2013

I think its still useful to have both, although I have a feeling that
something like the 'AWSOME' conversion layer from EC2 might still be a
pretty useful project to have to allow for a robust EC2 api which has a
dedicated group of people to support it. Never was quite sure what
happened to that project.


I might even take this further and propose that the nova-api binary itself
should/could be this 'conversion layer' as a separate project and then
allowing nova (the rest of the binaries) to be everything under said API
(the MQ would then be more of nova's 'exposed' API). Then the exposed WS
api can be whatever is best at that layer, whether it be ec2 or the native

But as for which one should be supported, I think this is an evolutionary
thing, whichever is most used and supported will be what openstack uses;
if that¹s the ec2 api or the native nova-api then so be it. Perhaps this
is another good reason for nova-api as its own project, let that battle be
fought in said project instead of having the nova project deal with that


On 7/24/13 11:06 AM, "Sean Dague" <sean at dague.net> wrote:

>On 07/24/2013 01:43 PM, Mark McLoughlin wrote:
>> On Wed, 2013-07-24 at 08:51 -0700, Stefano Maffulli wrote:
>>> Hello
>>> I have seen lots of discussions on blogs and twitter heating up around
>>> Amazon API compatibility and OpenStack. This seems like a recurring
>>> topic, often raised by pundits and recently joined by members of the
>>> community. I think it's time to bring the discussions inside our
>>> community to our established channels and processes. Our community has
>>> established ways to discuss and take technical decisions, from the more
>>> accessible General mailing list to the Development list to the Design
>>> Summits, the weekly project meetings, the reviews on gerrit and the
>>> governing bodies Technical Committee and Board of Directors.
>>> While we have not seen a large push in the community recently via
>>> contributions or deployments, Amazon APIs have been an option for
>>> deployments from the early days of OpenStack.
>>> I would like to have this discussion inside the established channels of
>>> our community and get the opinions from those that maintain that
>>> OpenStack should increase efforts for Amazon APIs compatibility, and
>>> ultimately it would be good to see code contributions.
>>> Do you think OpenStack should have an ongoing effort to imitate
>>> API? If you think it should, how would you lead the effort?
>> I think AWS compatible APIs for any of our services is a great feature.
>> I'd love to tell people they can try out OpenStack by pointing their
>> existing AWS based deployment tools at an OpenStack cloud.
>> Just yesterday, I saw a comment on IRC along the lines of "wow, Nova has
>> an EC2 API ... I should totally try out using knife with that".
>> Two things seem straightforward and obvious to me - our primary API is
>> the OpenStack "native" APIs and, yet, any built-in AWS compatibility we
>> can get is mucho goodness.
>> That said, it's not "AWS compat == goodness" statements we need ... we
>> need people who are keen to contribute to the work.
>> However, the very least we should do is make it clear that if anyone
>> *does* step up and do that work, that we'll welcome the contributions
>> with open arms.
>+1. Also validation of those interfaces would be appreciated. Today the
>tempest 3rdparty gate tests use the boto library, which is a good first
>step, but doesn't validate the AWS API strongly.
>Those kinds of contributions are equally welcomed, we've even set aside
>a place dedicated to them in Tempest (tempest/thirdparty) where non
>"native" API testing can live.
>But again, what is lacking here is mostly contributions. The more the
>merrier, and there are still many places where people can leave their
>mark on the project.
>	-Sean
>Sean Dague
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org

More information about the OpenStack-dev mailing list