As some of you know, I agreed to propose, prepare and give a talk at
next month's US PyCon in Atlanta. I felt that it would be a missed opportunity
to have one of the biggest and most significant open source project in Python
not represented at the largest Python conference. The talk
On Mon, 14 Feb 2011 09:14:16 -0500, Ed Leafe e...@leafe.com wrote:
As some of you know, I agreed to propose, prepare and give a talk at
next month's US PyCon in Atlanta. I felt that it would be a missed
opportunity to have one of the biggest and most significant open source
project in
Jay Pipes wrote:
IMHO, we should not be letting *any* significant new code into
OpenStack projects without:
a) docstrings for all methods -- these turn into our API
documentation, so they are critical
Agreed.
b) Full RST docs for any new feature added. No exceptions.
One issue is that if
Eric,
Ordered delivery of messages is a feature that I recognize is central to the
design of a queue service. A queue must be durable (persistent) in order to
provide reliable ordering capability. Having this feature simplifies
implementation of applications that consume the queue. I agree
Pete,
Queues are essential for highly concurrent use cases, and batch processing.
It's the core of what you need to build a cloud-specific application. Reference:
http://www.eecs.harvard.edu/~mdw/proj/seda/
Adrian
On Feb 14, 2011, at 10:20 AM, Pete Zaitcev wrote:
On Mon, 14 Feb 2011
On Sun, Feb 13, 2011 at 01:37:29PM -0500, Todd Willey wrote:
On Wed, Feb 9, 2011 at 1:38 PM, Eric Day e...@oddments.org wrote:
* Firehouse - So far we've not discussed this too much, but I
think when we did there was agreement that we need it. As more
service come into the picture, we
Hi Pete,
Two initial use cases are a comparable service to what other public
cloud providers already have (similar HTTP/REST API, but eventually
with more features) and a flexible, high-performance queue/event system
for backend log and event processing for other OpenStack services (see
the
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
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 part of
the core API, and I'd include images volumes in that list.
I think that
Eric,
Just looking at the http operations. Shouldn't the calls be around the
account then the queue?
GET /$account_id/queue/id to list all the queues
GET /$account_id/queue/id/message/id
Am I off here? Thoughts?
pvo
On 2/14/11 5:07 PM, Eric Day e...@oddments.org wrote:
I've summarized
Yeah, for anonymous access that would be the case. Those are not needed
when the request comes in with OpenStack Auth headers (like nova).
Do you think we should be repeating the account id in the URI when
the auth headers are present?
-Eric
On Mon, Feb 14, 2011 at 11:44:58PM +, Paul Voccio
Thoughts below
From: Justin Santa Barbara jus...@fathomdb.commailto:jus...@fathomdb.com
Date: Mon, 14 Feb 2011 15:40:04 -0800
To: Paul Voccio paul.voc...@rackspace.commailto:paul.voc...@rackspace.com
Cc: openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net
On Tue, Feb 15, 2011 at 12:49:01AM +, Paul Voccio wrote:
Dropping the account_id, would this also assume that there can be more
than one queue per account?
Yeah. Think of the queue name as an extra namespace layer much like
a swift container, except you don't create or delete them, they
Looking at the swift docs, they reference a container like so:
METHOD /v1/account/container HTTP/1.1
http://docs.rackspacecloud.com/files/api/v1/cf-devguide-20110112.pdf
For the openstack api, it also includes the account id in the request:
POST /v1.1/214412/images HTTP/1.1
Host:
On Mon, Feb 14, 2011 at 7:57 PM, Paul Voccio paul.voc...@rackspace.com wrote:
Looking at the swift docs, they reference a container like so:
METHOD /v1/account/container HTTP/1.1
Yeah, this has worked out well for us. Delegated access,
authentication methods that don't provide the account
22 matches
Mail list logo
