Open Stack

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
).

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130713/113ab5f5/attachment.html>