Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <CD0B20CA.2A3ED%murali.reddy@citrix.com>
References: 
 <CAKprHVY-RNTP=QQ78Ko=Jkw9Ff360WqydxUPyMJ6jg_0wqpA9g@mail.gmail.com>
	<CD0B20CA.2A3ED%murali.reddy@citrix.com>
Date: Thu, 3 Jan 2013 09:16:53 -0500
Message-ID: 
 <CA+96GG5aN0RGP+bsLLtavUFpPizgeVbuQR1dHtTgjPpuomNrhg@mail.gmail.com>
Subject: Re: [Discuss] SNMP Alerts support in CloudStack
From: Chip Childers <chip.childers@sungard.com>
To: "cloudstack-dev@incubator.apache.org"
 <cloudstack-dev@incubator.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Jan 3, 2013 at 1:31 AM, Murali Reddy <Murali.Reddy@citrix.com> wrote:
> On 03/01/13 12:33 AM, "David Nalley" <david@gnsa.us> wrote:
>>Interesting stuff. How and why did you decide on RabbitMQ?
>
> David,
>
> Default plug-in I am adding for event bus assumes AMQP. I have used
> RabbitMQ AMQP client. But the AMQP server it self could be any
> implementation of AMQP. Though I have not tested, RabbitMQ AMQP client is
> interoperable with Qpid [1]
>
> [1] http://www.rabbitmq.com/interoperability.html

AMQP versions matter quite a bit actually.  The Rabbit interop testing
is against Qpid 0.6, while the latest apache qpid release is 0.18.
AMQP isn't quite stable enough to assume that even the basic messaging
mechanics are the same really.

That doesn't mean that a Rabbit MQ implementation isn't good to
have...  it just means that it's not necessarily going to work with
every other AMQP broker implementation (or specific version).

>
>>I am specifically interested because RabbitMQ is not shipped in RHEL
>>but Qpid is and iirc RHT sells support for a qpid fork.
>>(Ubuntu 12.04 appears to ship both qpid and rabbitmq)
>>A user deploying CS on CentOS would need at least four additional
>>steps compared to qpid. (That isn't a technical reason, though all
>>else being equal I'd prefer to see us keep installation as simple as
>>possible. I also know that we release source, and the binary bits are
>>less of a concern, but we can't completely unplug from the reality our
>>end users face either)
>>
>>--David
>>
>
>
>