Preface: I am not very familiar with Nova.
On 08/26/2011 01:19 PM, Devin Carlen wrote:
I believe we should have had a Rackspace API module just like we have
an EC2 API module. Then the OpenStack API wouldn't have been
burdened by the historical decisions around the Rackspace API.
But that
The Rackspace compute API is actually one of the better cloud APIs out there.
It's a pretty damn good basis for an OpenStack Nova API.
EC2, on the other hand, is a pretty obnoxious API and I've already outlined my
thoughts on its role as a defacto API on my blog.
Having said that, there is
On Fri, Aug 26, 2011, Jesse Andrews anotherje...@gmail.com wrote:
I disagree. I find lots of valuable in github even if trunk merges
require gerrit.
Teams can (and IMHO should) use pull requests to improve the quality
before it is proposed to trunk. Pull requests to branches can be made
A cloud platform simply isn't functional without an API. It is a core
requirement.
No API, no cloud.
-George
On Aug 27, 2011, at 7:04 PM, Tim Bell wrote:
I'm also a non-API expert but getting a stable open cloud engine with a
reasonable API would seem to be a good target before we look to
I have an api, diablo nova v1.1.
What we are talking about is if it covers 100% functionality.
I can start my deployment testing with v1.1. The limiting factor is not v1.1
vs v1.x for most sites. It is packaging, user exits and integration, not
whether feature X is in the latest API.
Tim.
On 8/26/11 1:19 PM, Devin Carlen devin.car...@gmail.com wrote:
There have been a lot of efforts lately to bring the feature set of the
OpenStack API in line with the EC2 API, and this is admirable. But this
has NOT been happening at the architect level. This has been happening
at the
This is on the agenda for Tuesday's policy board meeting (in #openstack-meeting
1 hour before the weekly OpenStack team meeting for those interested). Sounds
like a potentially acceptable solution is to set some cross-project API
standards and then push the remainder of the API definition and
I don't necessarily agree with that approach. I'm not sure if that's the way
AWS does things or not, but you will note that the AWS APIs are very fragmented
across projects.
I think there are several principles that may at times be in conflict that need
to be in place:
* Any GA feature
8 matches
Mail list logo
