Open Stack

----- Original Message -----
> On 07/11/2013 12:06 PM, William Henry wrote:
> > 
> > 
> > ----- Original Message -----
> >> On 07/08/2013 10:51 AM, Ted Ross wrote:
> >>> If someone from the Qpid community were to work on integrating the new
> >>> AMQP 1.0 technology into OpenStack, where would be the right place to
> >>> start?  Would it be to add a new transport to oslo.messaging?
> >>
> >> I think so, yes.  oslo.messaging is new, but it will deprecate the
> >> existing 'rpc' library in oslo-incubator.  All projects will need to
> >> move to oslo.messaging, so for something new I would focus efforts there.
> > 
> > I think that one of the important points that Ted brought up is that AMQP
> > 1.0 doesn't have the concepts of broker artifacts like exchanges etc.
> > 
> > A recent change I proposed to the existing impl_qpid.py which focuses more
> > on addressing and not exchanges is a very important first step to solve
> > several issues: a recent qpidd leak issue, transitioning to AMQP 1.0
> > (addressing), and possible HA solutions.
> > 
> > This is an area I'd really like to continue to help out in. I'm back from
> > some vacation and would like to get stuck in soon.
> 
> Regarding the qpid exchange leak, that issue is mitigated largely by the
> fact that the only time we declare a direct exchange is for replies to
> an rpc.  In previous versions there was a new one of these for *every*
> method call, which made this problem really bad.  In the current code,
> we only create a single one.
> 
> However, we're still left with a leak.  The fact that RabbitMQ supports
> auto-delete on exchanges and Qpid doesn't is what got us into this spot,
> since this code works just like the kombu driver with respect to all of
> this.

Right you still have the leak. Right auto-delete on exchanges in Qpid would mitigate. 
 
Qpid never supported this because, to my knowledge, auto-delete on exchanges didn't mean anything or have any value in Qpid. I'm not sure it was ever mentioned in the old pre AMQP 1.0 spec. (I'd need to check).

And anyway exchanges don't mean anything in AMQP anymore. And don't mean anything in nonAMQP messaging - though AMQP implementations are not prohibited from implementing the queue/topic/fanout using exchange patterns.

> 
> As for migration to AMQP 1.0, how do these changes help?  Supporting
> AMQP 1.0 requires an entirely new driver that uses Qpid Proton, right?
> How does changing addressing in the current Qpid driver (that will never
> do 1.0) help?

Actually Qpid project saw the pending AMQP 1.0 ramifications early on and created an addressing mechanism that supported AMQP 1.0 addressing in Qpid long before Qpid/Proton.

So the changes I made recently would mean a simplified driver migration process.

But you are correct, it would still need that migration to a new driver.

It's my opinion that moving from a driver I recently submitted to the new driver would be very simple because of the way I've restructured the addressing.

All great points you raise Russell.

William

> 
> I'm curious what you mean by "possible HA solutions".  Can you elaborate?
> 
> --
> Russell Bryant
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>