: openstack@lists.launchpad.net
Subject: Re: [Openstack] Queue Service, next steps
Eric,
Thank you.
You raise lots of interest points. In no particular order:-
AMQP Observations
Your comments about AMQP seem to mostly be appropriate for one of the older
versions, eg 0-8, and I don't think
Hi Raphael,
On Mon, Feb 28, 2011 at 10:01:55AM +, Raphael Cohn wrote:
AMQP Observations
Your comments about AMQP seem to mostly be appropriate for one of the
older versions, eg 0-8, and I don't think they particularly apply to later
versions, eg 1-0. AMQP 0-8 did have some
Eric Team,
OpenStack's QueueService seems very interesting. As we have an existing
message queue implementation, we'd be happy to help you guys out. We're
about making messaging cloud-scale, so that everyone benefits.
However, it worries us that you're planning to implement a REST API for
Hi Raphael,
On Sun, Feb 27, 2011 at 11:18:35AM +, Raphael Cohn wrote:
OpenStack's QueueService seems very interesting. As we have an existing
message queue implementation, we'd be happy to help you guys out. We're
about making messaging cloud-scale, so that everyone benefits.
; openstack@lists.launchpad.net
Subject: Re: [Openstack] Queue Service, next steps
Please bear in mind the long term maintainability of the openstack package.
One of the attractive features at the moment is that there are not
significant pre-reqs to set up the environment and most mass market
Quick comment on the languages from a dev community perspective:
The Nova/Swift community is Python-based, so you won't directly reuse
it, whether you use C++ or Erlang. For new contributors, you either
target very experienced C++ developers (to get concurrency/scalability
right), or
I am very concerned about seeing a lot of I'd love to learn Erlang on
something we probably don't want to screw up. At the same time, I know there's
a number of us very experienced with C/C++ (even with respect to
concurrency/scalability).
- Chris
On Feb 21, 2011, at 2:40 AM, Thierry Carrez
Please bear in mind the long term maintainability of the openstack package.
One of the attractive features at the moment is that there are not significant
pre-reqs to set up the environment and most mass market environments can
support it.
Using C++ would not significantly change this
When you want to modify messages in a queue and also return those
that were modified. This is the atomic get/set needed by workers.
POST /account/queue?hide=60 HTTP/1.1
This will return all messages currently in /account/queue, but also
mark them as hidden for 60 seconds. This ensures only one
Hi Todd,
That's the multicast example, for a normal 1-1 queue, look at the
first example:
Worker: POST /account/queue?wait=60hide=60detail=all
(long-polling worker, request blocks until a message is ready)
Client: PUT /account/queue
(message inserted, returns unique id that was created)
Hi Mike,
On Sat, Feb 19, 2011 at 07:42:12PM -0600, Michael Barton wrote:
On Fri, Feb 18, 2011 at 9:38 PM, Eric Day e...@oddments.org wrote:
Hi Mike,
You make a good point, I apologize for not documenting some of the
ideas sooner. The architecture I had in mind borrows from other
queue
I have been meaning to reply with the exact same thing.
On Feb 18, 2011, at 10:12 AM, Jay Pipes jaypi...@gmail.com wrote:
Personally, I'd prefer C++ since that's what I'm used to, but I'd be
open to learning Erlang, too. Been wanting to learn it for a while
now.
-jay
On Fri, Feb 18,
would be easier.Cheersk/
Original Message
Subject: Re: [Openstack] Queue Service, next steps
From: Daniel Salinas imsplit...@gmail.com
Date: Fri, February 18, 2011 8:20 am
To: "openstack@lists.launchpad.net" openstack@lists.launchpad.net
I would totally be
Personally, I've been interested in learning Erlang as well. Eric, could you
explain more about why you anticipate that the queuing service will CPU-bound?
In either case, I've heard that Erlang can actually make better use of
multi-procs than C++, but I don't have any experience to speak from.
On 2/17/11 4:21 PM, Eric Day wrote:
Thanks to everyone who gave great feedback on the first queue service
thread. I've updated the wiki page to include the suggestions.
http://wiki.openstack.org/QueueService
Pondering this, I have a few thoughts:
I'll note that Erlang seems a realistic
On Fri, Feb 18, 2011 at 11:20:23AM -0600, Monsyne Dragon wrote:
Secondly, could we leverage existing opensource codebases to
accomplish this? I know AMQP was having issues over WAN links, and
likely isn't suited for disconnected operations (I've seen one
multitenant hosted queueing service
@lists.launchpad.net
Subject: Re: [Openstack] Queue Service, next steps
I checked out the CDMI spec, and while it covers the basics, it doesn't
seem to include features for visibility, concurrency control (multiple
workers grabbing messages via atomic operations), or long-polling. We
can still support
On Fri, Feb 18, 2011 at 5:22 PM, Eric Day e...@oddments.org wrote:
The main question right now is where to land on the spectrum of service
efficiency vs ease of development (C/C++ on one end and Python on
the other). It seems we're landing in the middle with Erlang. :)
Maybe I'm describing a
On Fri, Feb 18, 2011 at 6:23 PM, Eric Day e...@oddments.org wrote:
Perhaps I've been assuming some things, but I thought everyone
understood that is what we are looking to build (fault-tolerant,
horizontally scalable, ...). We're certainly not looking to build
a clustered queue (like RabbitMQ)
Thanks to everyone who gave great feedback on the first queue service
thread. I've updated the wiki page to include the suggestions.
http://wiki.openstack.org/QueueService
With a decent vision of what we want to build, the next step is
figuring out how. In a previous thread it was suggested that
20 matches
Mail list logo
