Open Stack

On 16/12/13 10:37 +0000, Gordon Sim wrote:
>On 12/12/2013 02:14 PM, Flavio Percoco wrote:
>>I've a draft in my head of how the amqp 1.0 driver could be
>>implemented and how to map the current expectations of the messaging
>>layer to the new protocol.
>>
>>I think a separate thread to discuss this mapping is worth it. There
>>are some critical areas that definitely need more discussion
>
>I have also been looking at this, and trying to write up a simple 
>design notes. Some of the questions that occurred to me while doing so 
>are:
>
>* Use one link for all sends, with 'to' field set, or use a link for 
>each target?

I like this proposal. It keeps messages atomic and isolated from the
rest of the environment. The only I can think OTO is: What happens if
the node that the reply should go to dies before the reply is sent?

Is this something we should be worrying about? I mean, if the node
that was waiting for the response dies, I think we'd have bigger
problems than just a 'missed response' :D. However, this doesn't mean
we couldn't take care of that.

>* How to handle calls to one of a group of servers?

Could you elaborate more what issues you see around this?

>
>* Use a distinct response address per request, or allow an address to 
>be shared by multiple requests in conjunction with correlation id on 
>responses?

mmh, this is an interesting one. Using a distinct address for
responses will make the implementation less error prone. However, I
don't really think we need to have different addresses since there's
already a way to distinguish multiple requests. So, I'd prefer the
later.

>
>* Support both intermediated and direct communication? For all patterns?

Besides fanout, I'd say yes. We need to support intermediated and
direct communication.

>The aim in my view should be to have the driver support as many 
>alternatives in deployment as possible without overcomplicating 
>things, distorting the mapping or introducing server specific 
>extensions.
>
>I have some notes to share if anyone is interested. I can send them to 
>this list or put them upon the wiki or an etherpad or something.

I think this questions are worth raising - thanks for that - and I
agree with you about not overcomplicating things. I think we could
start working something out and then we'll face different issues that
we'll need to discuss further on this list.

Cheers,
FF

-- 
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131217/0729dfc9/attachment.pgp>