Open Stack

----- Original Message -----

> On Fri, Jul 12, 2013 at 8:09 PM, William Henry < whenry at redhat.com > wrote:

> > Sent from my iPhone
> 

> > On Jul 12, 2013, at 5:27 PM, Doug Hellmann < doug.hellmann at dreamhost.com >
> > wrote:
> 

> > > On Fri, Jul 12, 2013 at 5:40 PM, William Henry < whenry at redhat.com >
> > > wrote:
> > 
> 

> > > > Hi all,
> > > 
> > 
> 

> > > > I've been reading through the Messaging Wiki and have some comments.
> > > > Not
> > > > criticisms, just comments and questions.
> > > 
> > 
> 
> > > > I have found this to be a very useful document. Thanks.
> > > 
> > 
> 

> > > > 1. "There are multiple backend transport drivers which implement the
> > > > API
> > > > semantics using different messaging systems - e.g. RabbitMQ, Qpid,
> > > > ZeroMQ.
> > > > While both sides of a connection must use the same transport driver
> > > > configured in the same way, the API avoids exposing details of
> > > > transports
> > > > so
> > > > that code written using one transport should work with any other
> > > > transport."
> > > 
> > 
> 

> > > > The good news for AMQP 1.0 users is that technically "boths sides of
> > > > the
> > > > connection" do not have to use same transport driver. In pre-AMQP 1.0
> > > > days
> > > > this was the case. But today interoperability between AMQP 1.0
> > > > implementations has been demonstrated.
> > > 
> > 
> 

> > > In this case I think we mean the Transport driver from within Oslo. So
> > > you
> > > could not connect a ZMQ Transport on one end to an AMQP Transport on the
> > > other. It will be an implementation detail of the AMQP Transport class to
> > > decide whether it supports more than one version of AMQP, or if the
> > > different versions are implemented as different Transports.
> > 
> 

> > > > 2. I notice under the RPC concepts section that you mention Exchanges
> > > > as
> > > > a
> > > > container in which topics are scoped. Is this exchange a pre AMQP 1.0
> > > > artifact or just a general term for oslo.messaging that is loosely
> > > > based
> > > > on
> > > > the pre-AMQP 1.0 artifact called an Exchange? i.e. are you assuming
> > > > that
> > > > messaging implementations have something called an exchange? Or do you
> > > > mean
> > > > that messaging implementations can scope a topic and in oslo we call
> > > > that
> > > > scoping an exchange?
> > > 
> > 
> 

> > > The latter.
> > 
> 

> > Ack. Good. Fits very well into AMQP 1.0 then ;-)
> 

> > > > 3. Some messaging nomenclature: The way the wiki describes RPC " Invoke
> > > > Method on One of Multiple Servers " is more like a queue than a topic.
> > > > In
> > > > messaging a queue is something that multiple consumers can attach to
> > > > and
> > > > one
> > > > of them gets and services a message/request. A topic is where 1+
> > > > consumers
> > > > are "connected" and each receives a the message and each can service it
> > > > as
> > > > it sees fit. In pre-AMQP 1.0 terms what this seems to describe is a
> > > > direct
> > > > exchange. And a direct excahnge can have multiple consumers listening
> > > > to
> > > > a
> > > > queue on that exchange. (Remember that fanout is just a generalization
> > > > of
> > > > topic in that all consumers get all fanout messages - there are no
> > > > sub-topics etc.)
> > > 
> > 
> 

> > > > In AMQP 1.0 the addressing doesn't care or know about exchanges but it
> > > > can
> > > > support this queue type behavior on an address or topic type behavior
> > > > on
> > > > an
> > > > address.
> > > 
> > 
> 

> > > > I know this isn't about AMQP specifically but therefore this is even
> > > > more
> > > > important. Topics are pub/sub with multiple consumer/services
> > > > responding
> > > > to
> > > > a single message. Queues are next consumer up gets the next message.
> > > 
> > 
> 

> > > > (BTW I've seen this kind of confusion also in early versions of
> > > > MCollective
> > > > in Puppet.)
> > > 
> > 
> 

> > > > It might be better to change some of the references to "topic" to
> > > > "address".
> > > > This would solve the problem. i.e. a use case where one of many servers
> > > > listening on an address services a message/request. And later all of
> > > > servers
> > > > listening on an address service a message/request. Addressing also
> > > > solves
> > > > the one-to-one as the address is specific to the server (and the others
> > > > don't have to receive and reject the message).
> > > 
> > 
> 

> > > Too many of these terms are overloaded. :-)
> > 
> 

> > Yep. But topic pup/sub is certainly different to a queue. ;-)
> 

> > > I'm not sure of the details of how "topic" and "address" are different in
> > > AMQP 1.0. The word "address" implies to me that the message sender knows
> > > where the message receiver is in some concrete sense. We don't want those
> > > semantics in a lot of our use cases. If the "address" is abstract, then
> > > it
> > > sounds like it works much as a topic does. Maybe you can expand on the
> > > differences?
> > 
> 

> > Nope the address is essentially a namespace. The send knows not where it
> > ends
> > up. Hence in some applications it doesn't even know of its a topic or a
> > queue an it could go to one or many depending.
> 

> OK, that sounds like it would be part of the Transport's handling of a Target
> (
> https://github.com/markmc/oslo.messaging/blob/master/oslo/messaging/target.py
> ).

Thanks Doug. This is interesting. What's the difference between an exchange and a namespace? If exchange is a scope and namespace is essentially a scope, then why have both? 

William 

> Doug

> > William
> 

> > > Thanks,
> > 
> 
> > > Doug
> > 
> 

> > > > Please feel free to respond and critique my comments/suggestions.
> > > 
> > 
> 

> > > > Best,
> > > 
> > 
> 
> > > > William
> > > 
> > 
> 

> > > > _______________________________________________
> > > 
> > 
> 
> > > > OpenStack-dev mailing list
> > > 
> > 
> 
> > > > OpenStack-dev at lists.openstack.org
> > > 
> > 
> 
> > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > > 
> > 
> 

> > > _______________________________________________
> > 
> 
> > > OpenStack-dev mailing list
> > 
> 
> > > OpenStack-dev at lists.openstack.org
> > 
> 
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > 
> 

> > _______________________________________________
> 
> > OpenStack-dev mailing list
> 
> > OpenStack-dev at lists.openstack.org
> 
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130715/957b8306/attachment.html>