This was an excellent explanation. Thank you, Thierry.
-jay
On Fri, Feb 18, 2011 at 2:55 AM, Thierry Carrez thie...@openstack.org wrote:
Trey Morris wrote:
I don't like that it currently only runs on ubuntu + the ppa. If it
doesn't work with existing versions I think we're doing something
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
On the topic of a REST API for the queue, I think implementing the CDMI queue APIs might be a good choice.The spec is at http://www.snia.org/tech_activities/publicreview/CDMI_Spec_v1.01f_DRAFT.pdf. There are a few other things, but focus on Section 11 P.104, Queue Object Resources. BTW, cdmi-queue
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
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
The spec for 1.0 and 1.1 are pretty close. The extensions mechanism is the
biggest change, iirc.
I think the proxy would make sense if you wanted to have a single api. Not all
service providers will but I see this as entirely optional, not required to use
the services.
The push to get a
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
One option might be to build this directly in python using a high speed http
frame work like Facebook's Tornado. I have created a similar proprietary queue
system here internally using Tornado with a REST based access system to it. The
framework is pretty light weight and performs exceptionally
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
http://wiki.openstack.org/Governance/Approved/CoreDevProcess says:
We will use lazy consensus for the approval vote from the current
sub-project core developers. The lazy consensus process shall last
five days after the email is sent to the mailing list. During the
lazy consensus
A few emails back (I have been in meetings and travel for the past two weeks
so I am just catching up on email now), Jay pretty much described our plan
of setting up a bunch of machines in multiple configurations for use as a
test cluster.
Towards that goal I'd love to start compiling the various
Hi Everyone,
I have been following this blog in test environment with just one node
running.
I have completed till the process of
euca-run-instances $emi -k mykey -t m1.tiny
But all i am seeing now is the instance is just waiting for scheduling for
an Hr or so
RESERVATION r-lcb18uqx myproject
The way I see it, there isn't a singular OpenStack API (even today there is
swift, nova, and glance). OpenStack is a suite of IaaS each with their own API
– so there is a SUITE of standard OS APIs. And each OS service should strive
to define the canonical API for automating that particular
Whoops. Extension presentation link was broken.
Herehttp://wiki.openstack.org/JorgeWilliams?action=AttachFiledo=viewtarget=Extensions.pdf
is a working one.
From: Erik Carlin erik.car...@rackspace.commailto:erik.car...@rackspace.com
Date: Fri, 18 Feb 2011 16:32:30 -0600
To: Justin Santa
Hi :)
This is probably something you want to move to the questions and answers
section on Launchpad:
https://answers.launchpad.net/nova
And the first thing you will want to do is start to look at your logs in
/var/log/nova
--andy
On Fri, Feb 18, 2011 at 2:30 PM, Harshavardhana
Thanks Andy already did.
On Fri, Feb 18, 2011 at 2:49 PM, Andy Smith andys...@gmail.com wrote:
Hi :)
This is probably something you want to move to the questions and answers
section on Launchpad:
https://answers.launchpad.net/nova
And the first thing you will want to do is start to look
I find this even more confusing than before. On the one hand, we talk about
a suite of independent APIs, and on the other hand we talk about binding
them together using extensions. We talk about standardizing around one API,
and we talk about letting a thousand flowers bloom as extensions.
I'm
I think I understand your confusing Justin. Extensions are not there to bind
APIs together. The examples I gave were probably a bit misleading. Extensions
are there to support niche functionality and to allow developers to innovate
without having to wait for some centralized group to
I have some anecdotal evidence to add to this from my time at Google:
(1) At Google in all reality you spent at least 2 days a week pretty much
only participating in code review and mailing list responses. This is due to
a couple things, but mostly because code review is taken extremely
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)
23 matches
Mail list logo
