There are lots of advantages:
1) It allows services to be more autonomous, and gives us clearly defined
service boundaries. Each service can be treated as a black box.
2) All service communication becomes versioned, not just the public API but
also the admin API. This means looser coupling
On Feb 18, 2011, at 9:34 AM, Jay Pipes wrote:
OK, fair enough.
Can I ask what the impetus for moving from AMQP to REST for all
internal APIs is? Seems to me we will be throwing away a lot of
functionality for the benefit of cross-WAN REST communication?
-jay
Not to mention building a
More inline. I trimmed your agrees.
On 2/18/11 10:27 AM, Jay Pipes jaypi...@gmail.com wrote:
5) Interested developers can get involved in only the services that
they care about without worrying about other services.
Not quite sure how this has to do with REST vs. AMQP... AMQP is simply
the
: [Openstack] OpenStack Compute API 1.1
Jay: The AMQP-REST was the re-architecting I was referring to, which would not
be customer-facing (other than likely introducing new bugs.) Spinning off the
services, if this is visible at the API level, is much more concerning to me.
So Paul, I think the proxy
On Feb 18, 2011, at 11:53 AM, Jay Pipes wrote:
I think your points are all valid, Jorge. Not disagreeing with them;
more just outlining that while saying all services must *publish* a
REST interface, services can listen and respond on more than one
protocol.
I'm glad we're *mostly* in agreement
openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net
Subject: Re: [Openstack] OpenStack Compute API 1.1
How is the 1.1 api proposal breaking this?
Because if we launch an OpenStack API, the expectation is that this will be the
OpenStack API :-)
If we support a third-party API
openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net
Subject: Re: [Openstack] OpenStack Compute API 1.1
How is the 1.1 api proposal breaking this?
Because if we launch an OpenStack API, the expectation is that this will be the
OpenStack API :-)
If we support a third-party API
@lists.launchpad.net openstack@lists.launchpad.net
Subject: Re: [Openstack] OpenStack Compute API 1.1
How is the 1.1 api proposal breaking this?
Because if we launch an OpenStack API, the expectation is that this will
be the OpenStack API :-)
If we support a third-party API (CloudServers or EC2
@lists.launchpad.netmailto:openstack@lists.launchpad.net
Subject: Re: [Openstack] OpenStack Compute API 1.1
How is the 1.1 api proposal breaking this?
Because if we launch an OpenStack API, the expectation is that this will be the
OpenStack API :-)
If we support a third-party API (CloudServers or EC2
] OpenStack Compute API 1.1
Sounds great - when the patch comes in we can discuss whether this should be an
extension or whether scheduled snapshots / generic tasks have broader
applicability across OpenStack (and thus would be better in the core API)
Is there a blueprint?
On Tue, Feb 15, 2011 at 11
11:38:37 -0800
To: Troy Toman troy.to...@rackspace.com
Cc: openstack@lists.launchpad.net openstack@lists.launchpad.net
Subject: Re: [Openstack] OpenStack Compute API 1.1
Sounds great - when the patch comes in we can discuss whether this should
be an extension or whether scheduled snapshots
On Thu, Feb 17, 2011 at 6:57 PM, Justin Santa Barbara
jus...@fathomdb.com wrote:
Pulling volumes images out into separate services (and moving from AMQP to
REST) sounds like a huge breaking change, so if that is indeed the plan,
let's do that asap (i.e. Cactus).
Sorry, I have to disagree with
An API is for life, not just for Cactus.
I agree that stability is important. I don't see how we can claim to
deliver 'stability' when the plan is then immediately to destablize
everything with a very disruptive change soon after, including customer
facing API changes and massive internal
Sorry, I don't view the proposed changes from AMQP to REST as being
customer facing API changes. Could you explain? These are internal
interfaces, no?
-jay
On Thu, Feb 17, 2011 at 8:13 PM, Justin Santa Barbara
jus...@fathomdb.com wrote:
An API is for life, not just for Cactus.
I agree that
The proposed compute API 1.1 has a specification for server actions (Sec. 4.4)
with the endpoint:
/servers/{id}/action
The actual action is specified as the body of the POST request, and the
implication is that the action is performed immediately, or as soon as possible.
I'd like us to
On Wed, Feb 16, 2011 at 5:02 PM, Glen Campbell
glen.campb...@rackspace.com wrote:
The proposed compute API 1.1 has a specification for server actions (Sec.
4.4) with the endpoint:
/servers/{id}/action
The actual action is specified as the body of the POST request, and the
implication is
I like this idea, but I would suggest going with a unix timestamp in GMT
instead of /2011/xx/xx/etc.
Also, how would this effect error handling? It seems like you'd basically need
to have some sort of way to query all the server actions you've ever done
before with their HTTP responses.
On
-Original Message-
From: Jay Pipes jaypi...@gmail.com
Sent: Wednesday, February 16, 2011 5:09pm
To: Glen Campbell glen.campb...@rackspace.com
Cc: openstack@lists.launchpad.net openstack@lists.launchpad.net
Subject: Re: [Openstack] OpenStack Compute API 1.1 ‹ server actions
On Wed
How would this work if someone didn't run a volume service or glance?
Should the api listen for that?
My expectation is that if someone didn't run a volume service, we should
expose that just as if there were insufficient resources (because that's not
far from the case.) We'd return an error
On Feb 15, 2011, at 1:06 PM, Justin Santa Barbara wrote:
OK - so it sounds like volumes are going to be in the core API (?) - good.
Let's get that into the API spec. It also sounds like extensions (swift /
glance?) are not going to be in the same API long-term. So why do we have the
On Feb 15, 2011, at 1:06 PM, Justin Santa Barbara wrote:
How would this work if someone didn't run a volume service or glance? Should
the api listen for that?
My expectation is that if someone didn't run a volume service, we should expose
that just as if there were insufficient resources
Bumping this to the top of the list. One of the key deliverables for Cactus
is a complete and usable OpenStack Compute API. This means that using only
the API and tools that interact with the OpenStack Compute API Nova can be
installed and configured; once running all of the Nova features and
The reason I haven't responded yet is because it's difficult for me to:
diff -u some.pdf other.pdf
In all seriousness, the wiki spec page says this about the differences
in the 1.1 OpenStack API:
==start wiki==
OS API 1.1 Features
IPv6
Extensions
Migrate to OpenStack namespace
==end wiki==
On Feb 14, 2011, at 3:08 PM, Jay Pipes wrote:
The reason I haven't responded yet is because it's difficult for me to:
diff -u some.pdf other.pdf
In all seriousness, the wiki spec page says this about the differences
in the 1.1 OpenStack API:
I'll work with Anne to make the source
On Mon, Feb 14, 2011 at 4:27 PM, Jorge Williams
jorge.willi...@rackspace.com wrote:
On Feb 14, 2011, at 3:08 PM, Jay Pipes wrote:
I'll work with Anne to make the source documents available to you guys so you
can do a diff etc. Give me a couple of days to get this working, existing
docs are
On Feb 14, 2011, at 3:35 PM, Jay Pipes wrote:
On Mon, Feb 14, 2011 at 4:27 PM, Jorge Williams
jorge.willi...@rackspace.com wrote:
On Feb 14, 2011, at 3:08 PM, Jay Pipes wrote:
I'll work with Anne to make the source documents available to you guys so
you can do a diff etc. Give me a couple
On Mon, Feb 14, 2011 at 4:39 PM, Gabe Westmaas
gabe.westm...@rackspace.com wrote:
Thanks Jay, I promise I will make more useful wikis soon :)
Hehe, sorry if I came across as grumpy. Was just doing some old
fashioned rib-poking, that's all ;)
Jorge answered most of the questions you had, I just
Some thoughts...
General:
- Are we writing the OpenStack API, or are we writing the document for
the next version of Cloud Servers? In my opinion, the two need to be
separate. For example, specifications of resource limits and rate limits,
supported compression encodings, timeout
Thoughts below:
From: Justin Santa Barbara jus...@fathomdb.commailto:jus...@fathomdb.com
Date: Mon, 14 Feb 2011 14:32:52 -0800
To: openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net
Subject: Re: [Openstack] OpenStack Compute API 1.1
Some thoughts...
General:
* Are we
-0800
To: openstack@lists.launchpad.net
Subject: Re: [Openstack] OpenStack Compute API 1.1
Some thoughts...
General:
- Are we writing the OpenStack API, or are we writing the document for
the next version of Cloud Servers? In my opinion, the two need to be
separate
@lists.launchpad.netmailto:openstack@lists.launchpad.net
Subject: Re: [Openstack] OpenStack Compute API 1.1
Ah - well, I was sort of expecting that we'd all go the other way and agree
some core functionality, and I thought that volumes should definitely be part
of that. I'd hope that the core functionality would
31 matches
Mail list logo
