efacto standard way for automating
that service.
Erik
From: Justin Santa Barbara mailto:jus...@fathomdb.com>>
Date: Fri, 18 Feb 2011 09:57:12 -0800
To: Paul Voccio mailto:paul.voc...@rackspace.com>>
Cc: "openstack@lists.launchpad.net<mailto:openstack@lists.launchpad.net>"
tomating that service.
>
> Erik
>
> From: Justin Santa Barbara
> Date: Fri, 18 Feb 2011 09:57:12 -0800
>
> To: Paul Voccio
> Cc: "openstack@lists.launchpad.net"
>
> Subject: Re: [Openstack] OpenStack Compute API 1.1
>
> > How is the 1.1 api proposal breakin
a Barbara mailto:jus...@fathomdb.com>>,
Paul Voccio mailto:paul.voc...@rackspace.com>>
Cc: "openstack@lists.launchpad.net<mailto:openstack@lists.launchpad.net>"
mailto:openstack@lists.launchpad.net>>
Subject: Re: [Openstack] OpenStack Compute API 1.1
The way I see it,
ilto:openstack@lists.launchpad.net>"
mailto: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
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
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.
So, I agree with you basically, just pointing out that while having a
REST interface i
ow is the 1.1 api proposal breaking this?
>
> From: Justin Santa Barbara
> Date: Fri, 18 Feb 2011 09:10:19 -0800
> To: Paul Voccio
> Cc: Jay Pipes , "openstack@lists.launchpad.net" <
> openstack@lists.launchpad.net>
>
> Subject: Re: [Openstack] OpenStack C
On Feb 18, 2011, at 10:27 AM, Jay Pipes wrote:
> Hi Jorge! Thanks for the detailed response. Comments inline. :)
>
> On Fri, Feb 18, 2011 at 11:02 AM, Jorge Williams
> wrote:
>> There are lots of advantages:
>>
>> 1) It allows services to be more autonomous, and gives us clearly defined
>> se
-0800
To: Paul Voccio mailto:paul.voc...@rackspace.com>>
Cc: Jay Pipes mailto:jaypi...@gmail.com>>,
"openstack@lists.launchpad.net<mailto:openstack@lists.launchpad.net>"
mailto:openstack@lists.launchpad.net>>
Subject: Re: [Openstack] OpenStack Compute API 1.1
Jay
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 is good because it acknowledges th
More inline. I trimmed your agrees.
On 2/18/11 10:27 AM, "Jay Pipes" 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 communicati
Hi Jorge! Thanks for the detailed response. Comments inline. :)
On Fri, Feb 18, 2011 at 11:02 AM, Jorge Williams
wrote:
> 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.
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 build
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 whic
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
On Fri, Feb 18, 2011 at 9:31 AM, Paul Voccio wrote:
> Jay,
>
> I understand Justin
Jay,
I understand Justin's concern if we move /network and /images and /volume
to their own endpoints then it would be a change to the customer. I think
this could be solved by putting a proxy in front of each endpoint and
routing back to the appropriate service endpoint.
I added another image on
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
wrote:
> An API is for life, not just for Cactus.
> I agree that stability is import
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 re-arch
On Thu, Feb 17, 2011 at 6:57 PM, Justin Santa Barbara
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 you here, Justi
From: Justin Santa Barbara
> Date: Tue, 15 Feb 2011 11:38:37 -0800
> To: Troy Toman
>
> Cc: "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
>
...@fathomdb.com>>
Date: Tue, 15 Feb 2011 11:38:37 -0800
To: Troy Toman mailto:troy.to...@rackspace.com>>
Cc: "openstack@lists.launchpad.net<mailto:openstack@lists.launchpad.net>"
mailto:openstack@lists.launchpad.net>>
Subject: Re: [Openstack] OpenStack Compute API 1.1
Sounds
I like idea of scheduling actions overall. The idea of a generic scheduling
service also appeals to me a lot. The question is how do you generalize the
service. I'd love to see your write up.
-jOrGe W.
On Feb 16, 2011, at 4:35 PM, Adrian Otto wrote:
Glen,
I definitely recognize the value
On Feb 16, 2011, at 5:11 PM, Michael Mayo wrote:
> I like this idea, but I would suggest going with a unix timestamp in GMT
> instead of /2011/xx/xx/etc.
Whether you use a timestamp or MM... format, *always* use GMT. We
all know how much fun it is when someone in Europe sends a requ
Glen,
I definitely recognize the value in having scheduling capability. I wrote a
high level draft of a REST API for a generic scheduler to be used for batch job
processing. Scheduled events are discussed regularly by users of queue systems
that want certain things to happen on regular interval
On Wed, Feb 16, 2011 at 5:29 PM, Brian Waldon
wrote:
> -Original Message-
> From: "Jay Pipes"
> Sent: Wednesday, February 16, 2011 5:09pm
> To: "Glen Campbell"
> Cc: "openstack@lists.launchpad.net"
> Subject: Re: [Openstack] OpenStack Com
-Original Message-
From: "Jay Pipes"
Sent: Wednesday, February 16, 2011 5:09pm
To: "Glen Campbell"
Cc: "openstack@lists.launchpad.net"
Subject: Re: [Openstack] OpenStack Compute API 1.1 ‹ server actions
On Wed, Feb 16, 2011 at 5:02 PM, Glen Campbell
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
On Wed, Feb 16, 2011 at 5:02 PM, Glen Campbell
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 that the action is pe
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 cons
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 (be
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:32 AM, Troy Toman wrot
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
extens
> 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 er
<mailto:openstack@lists.launchpad.net>"
mailto: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
Additional comments inline:
On Feb 14, 2011, at 4:59 PM, Paul Voccio wrote:
Thoughts below:
From: Justin Santa Barbara mailto:jus...@fathomdb.com>>
Date: Mon, 14 Feb 2011 14:32:52 -0800
To: mailto:openstack@lists.launchpad.net>>
Subject: Re: [Openstack] OpenStack Compute API 1.1
S
et>>
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 always be p
your feedback,
> pvo
>
> From: Justin Santa Barbara
> Date: Mon, 14 Feb 2011 14:32:52 -0800
> To:
> Subject: Re: [Openstack] OpenStack Compute API 1.1
>
> Some thoughts...
>
> General:
>
>
>- Are we writing the OpenStack API, or are we writing the
t;>
Date: Mon, 14 Feb 2011 14:32:52 -0800
To: mailto: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 opini
Thoughts below:
From: Justin Santa Barbara mailto:jus...@fathomdb.com>>
Date: Mon, 14 Feb 2011 14:32:52 -0800
To: mailto:openstack@lists.launchpad.net>>
Subject: Re: [Openstack] OpenStack Compute API 1.1
Some thoughts...
General:
* Are we writing the OpenStack API, or are we
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 o
On Mon, Feb 14, 2011 at 4:39 PM, Gabe Westmaas
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 wanted to point out that
Thanks Jay, I promise I will make more useful wikis soon :) Jorge answered
most of the questions you had, I just wanted to point out that I pulled the
main IPv6 items out and put them in the wiki now. There isn't too much that
changed there, but wanted to point out what was new anyway.
Gabe
On Feb 14, 2011, at 3:35 PM, Jay Pipes wrote:
> On Mon, Feb 14, 2011 at 4:27 PM, Jorge Williams
> 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
On Mon, Feb 14, 2011 at 4:27 PM, Jorge Williams
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 built into the implementa
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 sour
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==
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
funct
47 matches
Mail list logo
