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

2013-07-27 Thread Burt Holzman
On 7/26/2013 10:39 AM, Jay Pipes wrote:
 On 07/26/2013 08:04 AM, Sean Dague wrote:
 Also there are EC2 design points that have request lengths greater than
 what Apache (or any other web front end) is compiled to support, as they
 have the possibility of enourmous GET strings (16K at least). Again,
 instead of sensibly requiring to move to POST in those cases. I know we
 had to land a change for CERN to allow bigger requests on EC2 calls for
 just this reason (we did keep the get length apache sized on OSAPI, so
 we didn't break people's attempts to get this behind a real web server).

I wrote that patch, so now I feel qualified to jump in this thread. :)

 However, I will say that developers write code to scratch an itch -- or
 some product manager's itch. So the fact that nobody is all that
 interested in spending time to code up enhanced EC2 API support in Nova
 is, well, quite telling that the demand for such things is less than
 what some people think.

I know that my user community has little to no experience with openstack
development, but our still nascent cloud infrastructure is built around
tools that speak EC2. API translation layers like Deltacloud are just
another layer we'd need to deploy, operate, monitor, and so on, and on
the whole I think we'd prefer for the compatibility to be built-in
rather than yet another service.

I disagree about measuring user demand -- it's not a great metric here.
When I tried to throw an issue over the wall to nova development, it got
thrown back and I was asked to sign the CLA and contribute directly*. I
think it's tough to gauge user demand if that's the usual answer to
missing API bits.

- B

* I'm not complaining about this -- it's the model for community-driven
development. (And I can only contribute parasitically, development isn't
my day job.)

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2013-07-26 Thread Sean Dague

On 07/25/2013 08:30 PM, Joshua Harlow wrote:

When you have so much state to maintain then aren't the APIs incorrect??


Yes, the EC2 APIs are incorrect in being silly and using ints for ids 
for so many things, also for supporting people to make GET requests with 
16k get strings. But there isn't much we can do about that. :)



Or can there be new API's that expose this translation, something
seems/feels wrong if there is so much state to maintain u can't do a
translation layer.


Most of this is about id allocation and translation. OpenStack uses 
UUIDs, AWS uses ints. UUIDs is a better design point, and means you 
don't need to have a global auto allocator which you can guaruntee, 
which is good.


Also there are EC2 design points that have request lengths greater than 
what Apache (or any other web front end) is compiled to support, as they 
have the possibility of enourmous GET strings (16K at least). Again, 
instead of sensibly requiring to move to POST in those cases. I know we 
had to land a change for CERN to allow bigger requests on EC2 calls for 
just this reason (we did keep the get length apache sized on OSAPI, so 
we didn't break people's attempts to get this behind a real web server).


Translation is never exact, go talk to the WINE folks about that one.

I'm personally fine either way, proxy or embedded in openstack. Which 
approach isn't really the issue. It's that no one is doing the work. 
Actions speak much louder than words (well... except in pundit echo 
chambers), so I'd much rather have people with strong opinions on this 
express how strongly those are by having a big patch queue for me to review.


-Sean


My 2 cents.

On 7/25/13 4:36 PM, Michael Still mi...@stillhq.com wrote:


On Fri, Jul 26, 2013 at 8:30 AM, Russell Bryant rbry...@redhat.com
wrote:


If an external proxy (like AWSOME) is what you want, one of those
already exists (at least for the EC2 API).

http://deltacloud.apache.org/

It supports EC2 on the frontend and the OpenStack compute API on the
backend.  I'm not sure how using this compares to the EC2 implementation
in nova, though.


I am sceptical of the external proxy approach as there is a lot of
state to maintain (uuid to id mappings for example) which is hard to
do right in a proxy. I like the idea of the AWS APIs being secondary
APIs within nova. However, its fair to say that there hasn't been much
work done on them recently.

Michael

--
Rackspace Australia

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




--
Sean Dague
http://dague.net

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2013-07-26 Thread Ben Nemec

On 2013-07-26 10:39, Jay Pipes wrote:

On 07/26/2013 08:04 AM, Sean Dague wrote:

On 07/25/2013 08:30 PM, Joshua Harlow wrote:
When you have so much state to maintain then aren't the APIs 
incorrect??


Yes, the EC2 APIs are incorrect in being silly and using ints for ids
for so many things, also for supporting people to make GET requests 
with

16k get strings. But there isn't much we can do about that. :)


Or can there be new API's that expose this translation, something
seems/feels wrong if there is so much state to maintain u can't do a
translation layer.


Most of this is about id allocation and translation. OpenStack uses
UUIDs, AWS uses ints. UUIDs is a better design point, and means you
don't need to have a global auto allocator which you can guaruntee,
which is good.

Also there are EC2 design points that have request lengths greater 
than
what Apache (or any other web front end) is compiled to support, as 
they

have the possibility of enourmous GET strings (16K at least). Again,
instead of sensibly requiring to move to POST in those cases. I know 
we
had to land a change for CERN to allow bigger requests on EC2 calls 
for

just this reason (we did keep the get length apache sized on OSAPI, so
we didn't break people's attempts to get this behind a real web 
server).


Translation is never exact, go talk to the WINE folks about that one.

I'm personally fine either way, proxy or embedded in openstack. Which
approach isn't really the issue. It's that no one is doing the work.
Actions speak much louder than words (well... except in pundit echo
chambers), so I'd much rather have people with strong opinions on this
express how strongly those are by having a big patch queue for me to
review.


Amen that that.

However, I will say that developers write code to scratch an itch --
or some product manager's itch. So the fact that nobody is all that
interested in spending time to code up enhanced EC2 API support in
Nova is, well, quite telling that the demand for such things is less
than what some people think.


I'm not sure this is a safe assumption to make.  It's only natural that 
the companies/people who are working on OpenStack would be more 
interested in the OS API, but that doesn't mean there aren't AWS users 
out there who would like to migrate off but don't have the expertise to 
contribute to OpenStack.


None of which changes the fact that without developer interest nothing 
is going to get done, but I still think it's important to keep in mind 
that developer interest does not necessarily equal user interest.  The 
fact that nobody is currently working on it doesn't mean there isn't an 
opportunity here.


-Ben

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2013-07-26 Thread Ben Nemec

On 2013-07-26 12:38, Russell Bryant wrote:

On 07/26/2013 11:53 AM, Ben Nemec wrote:

On 2013-07-26 10:39, Jay Pipes wrote:

On 07/26/2013 08:04 AM, Sean Dague wrote:

On 07/25/2013 08:30 PM, Joshua Harlow wrote:

When you have so much state to maintain then aren't the APIs
incorrect??


Yes, the EC2 APIs are incorrect in being silly and using ints for 
ids
for so many things, also for supporting people to make GET requests 
with

16k get strings. But there isn't much we can do about that. :)


Or can there be new API's that expose this translation, something
seems/feels wrong if there is so much state to maintain u can't do 
a

translation layer.


Most of this is about id allocation and translation. OpenStack uses
UUIDs, AWS uses ints. UUIDs is a better design point, and means you
don't need to have a global auto allocator which you can guaruntee,
which is good.

Also there are EC2 design points that have request lengths greater 
than
what Apache (or any other web front end) is compiled to support, as 
they

have the possibility of enourmous GET strings (16K at least). Again,
instead of sensibly requiring to move to POST in those cases. I know 
we
had to land a change for CERN to allow bigger requests on EC2 calls 
for
just this reason (we did keep the get length apache sized on OSAPI, 
so
we didn't break people's attempts to get this behind a real web 
server).


Translation is never exact, go talk to the WINE folks about that 
one.


I'm personally fine either way, proxy or embedded in openstack. 
Which

approach isn't really the issue. It's that no one is doing the work.
Actions speak much louder than words (well... except in pundit echo
chambers), so I'd much rather have people with strong opinions on 
this

express how strongly those are by having a big patch queue for me to
review.


Amen that that.

However, I will say that developers write code to scratch an itch --
or some product manager's itch. So the fact that nobody is all that
interested in spending time to code up enhanced EC2 API support in
Nova is, well, quite telling that the demand for such things is less
than what some people think.


I'm not sure this is a safe assumption to make.  It's only natural 
that

the companies/people who are working on OpenStack would be more
interested in the OS API, but that doesn't mean there aren't AWS users
out there who would like to migrate off but don't have the expertise 
to

contribute to OpenStack.

None of which changes the fact that without developer interest nothing
is going to get done, but I still think it's important to keep in mind
that developer interest does not necessarily equal user interest.  The
fact that nobody is currently working on it doesn't mean there isn't 
an

opportunity here.


If that demand is communicated by customers to vendors contributing to
OpenStack, and it is a higher priority than other things customers are
asking for, it will get worked on.  That just hasn't seemed to be the
case based on contribution activity.


Fair enough.  Just wanted to make sure we weren't stuck in a developer 
echo chamber and it sounds like we aren't, at least to the extent that 
it's possible for us to know.


-Ben

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2013-07-25 Thread Vishvananda Ishaya

On Jul 24, 2013, at 8:51 AM, Stefano Maffulli stef...@openstack.org 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 Amazon's
 API? If you think it should, how would you lead the effort?

Thanks for bringing this up Stefano. I think that there is a new driver
for amazon compatibility that has shown up recently: Netflix's efforts
to make their software stack Open Source[1]

The various projects that netflix has released are starting to get a lot
of attention from enterprises and companies wishing to become more agile.

Supporting other open source projects, especially ones that can be used
on top of OpenStack should be something that we encourage.

The greatest friction between netflix oss and openstack is lack of AWS
features[2] that are in use by their software (especially Asgard).

There are a couple of approaches here: one is to change the the other
open source software to use openstack apis natively. I think this
is best long term, but we have relatively little expertise in these
other projects, the easiest path forward is to do the best job we
can at supporting as many of the AWS apis as possible.

[1] http://netflix.github.io
[2] http://www.slideshare.net/adrianco/netflix-and-open-source/45

Vish

 
 
 /stef
 -- 
 Ask and answer questions on https://ask.openstack.org
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2013-07-25 Thread Thierry Carrez
Stefano Maffulli wrote:
 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.

Like you say, all this needs is people to start putting resources where
their mouth is and pushing improvements through our regular channels:
proposing a blueprint, discussing it at our summits, signing up to do an
actionable piece of work and deliver it in one of our development
milestones.

I don't think anyone argues that having AWS compatibility would be a bad
thing, as long as we keep a local API that lets us exhibit features that
are not (yet) in AWS APIs when those features make sense.

Having a common internal layer upon which the various external APIs can
plug is also pretty common sense, the historical reason we don't have
that yet was that nobody signed up to do the work, while at the same
time Canonical signed up to do the AWSOME proxy. Since apparently this
effort was abandoned, the road is open again, just waiting for cars to
pass on it.

-- 
Thierry Carrez (ttx)

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2013-07-25 Thread Russell Bryant
On 07/25/2013 06:11 PM, Thierry Carrez wrote:
 Stefano Maffulli wrote:
 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.
 
 Like you say, all this needs is people to start putting resources where
 their mouth is and pushing improvements through our regular channels:
 proposing a blueprint, discussing it at our summits, signing up to do an
 actionable piece of work and deliver it in one of our development
 milestones.
 
 I don't think anyone argues that having AWS compatibility would be a bad
 thing, as long as we keep a local API that lets us exhibit features that
 are not (yet) in AWS APIs when those features make sense.
 
 Having a common internal layer upon which the various external APIs can
 plug is also pretty common sense, the historical reason we don't have
 that yet was that nobody signed up to do the work, while at the same
 time Canonical signed up to do the AWSOME proxy. Since apparently this
 effort was abandoned, the road is open again, just waiting for cars to
 pass on it.
 

If an external proxy (like AWSOME) is what you want, one of those
already exists (at least for the EC2 API).

http://deltacloud.apache.org/

It supports EC2 on the frontend and the OpenStack compute API on the
backend.  I'm not sure how using this compares to the EC2 implementation
in nova, though.

-- 
Russell Bryant

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2013-07-25 Thread Michael Still
On Fri, Jul 26, 2013 at 8:30 AM, Russell Bryant rbry...@redhat.com wrote:

 If an external proxy (like AWSOME) is what you want, one of those
 already exists (at least for the EC2 API).

 http://deltacloud.apache.org/

 It supports EC2 on the frontend and the OpenStack compute API on the
 backend.  I'm not sure how using this compares to the EC2 implementation
 in nova, though.

I am sceptical of the external proxy approach as there is a lot of
state to maintain (uuid to id mappings for example) which is hard to
do right in a proxy. I like the idea of the AWS APIs being secondary
APIs within nova. However, its fair to say that there hasn't been much
work done on them recently.

Michael

--
Rackspace Australia

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2013-07-24 Thread Monty Taylor


On 07/24/2013 08:51 AM, 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 Amazon's
 API? If you think it should, how would you lead the effort?

I don't care about Amazon's APIs at all, except in as much as
compatibility shims might help people migrate off of a closed system and
on to an open one.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2013-07-24 Thread Russell Bryant
On 07/24/2013 11:57 AM, Monty Taylor wrote:
 
 
 On 07/24/2013 08:51 AM, 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 Amazon's
 API? If you think it should, how would you lead the effort?
 
 I don't care about Amazon's APIs at all, except in as much as
 compatibility shims might help people migrate off of a closed system and
 on to an open one.

I feel about the same way, but I think this reason is enough to have and
continue maintaining support for these APIs.

As Stefano said, at least in nova we haven't seen a whole *lot* of work
on the EC2 API support lately.  However, I don't see it going away in
the foreseeable future and would certainly welcome more contributions in
this area.

-- 
Russell Bryant

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2013-07-24 Thread Mark McLoughlin
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 Amazon's
 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.

Cheers,
Mark.


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2013-07-24 Thread Chmouel Boudjnah
On Wed, Jul 24, 2013 at 8:51 AM, Stefano Maffulli stef...@openstack.org wrote:
 Do you think OpenStack should have an ongoing effort to imitate Amazon's
 API? If you think it should, how would you lead the effort?

We (Swift) moved the S3 compatibiliy middleware out of core swift for
quite some in its own github repository[1] maintained by fujita and so
far this has been working well for us, since most of the Swift core
don't know (or care I guess) about S3 API and fujita does this
ensuring it works.

I personally don't see an advantage of having to support S3 (it's
basically a constant screenscraping) but like monty said I care much
more about facilitating migration for our users.

Chmouel.

[1] https://github.com/fujita/swift3

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2013-07-24 Thread Sean Dague

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 Amazon's
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
http://dague.net

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2013-07-24 Thread Joshua Harlow
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.

http://www.canonical.com/content/canonical%E2%80%99s-awsome-bridges-amazon-
and-openstack-clouds

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
nova-api.

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
api.

-Josh 

On 7/24/13 11:06 AM, Sean Dague s...@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
Amazon's
 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
http://dague.net

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev