Open Stack

Thanks Flavio, some comments inline below.

On 6/11/14, 5:15 AM, "Flavio Percoco" <flavio at redhat.com> wrote:

>>
>>  1.  Marconi exposes HTTP APIs that allow messages to be listed without
>>consuming them. This API cannot be implemented on top of AMQP 0.9 which
>>implements a strict queueing semantics.
>
>I believe this is quite an important endpoint for Marconi. It's not
>about listing messages but getting batch of messages. Wether it is
>through claims or not doesn't really matter. What matters is giving
>the user the opportunity to get a set of messages, do some work and
>decide what to do with those messages afterwards.

The sticky point here is that this Marconi¹s endpoint allows messages to
be obtained *without* consuming them in the traditional messaging system
sense: the messages remain visible to other consumers. It could be argued
that such semantics can be implemented on top of AMQP by first getting the
messages and then immediately releasing them for consumption by others,
before the Marconi call returns. However, even that is only possible for
messages that are at the front of the queue - the "paging" mechanism using
markers cannot be supported.

>>  3.  Marconi exposes HTTP APIs that allow queues to be created,
>>deleted, and listed. Queue creation and deletion can be implemented with
>>AMQP 0.9, but listing queues is not possible with AMQP. However, listing
>>queues can be implemented by accessing RabbitMQ management plugin over
>>proprietary HTTP APIs that Rabbit exposes.
>
>We were really close to get rid of queues but we decided to keep them
>around at the summit. One of the reasons to keep queues is their
>metadata - rarely used but still useful for some use cases.
>
>Monitoring and UIs may be another interesting use case to keep queues
>around as a first citizen resource.
>
>I must admit that keeping queues around still bugs me a bit but I'll
>get over it.

I suspect the metadata requirements will ultimately weigh a lot on this
decision, and I understand Marconi so far did not really have a smoking
gun case for queue metadata. In particular, if and when Marconi introduces
an authentication/authorization model, the ACLs will need to be stored and
managed somewhere. Queue metadata is a natural place to configure
per-queue security. Both SQS and Azure Storage Queues model it that way.

>>
>>  5.  Marconi message consumption API creates a ³claim ID² for a set of
>>consumed messages, up to a limit. In the AMQP 0.9 model (as well as SQS
>>and Azure Queues), ³claim ID² maps onto the concept of ³delivery tag²
>>which has a 1-1 relationship with a message. Since there is no way to
>>represent the 1-N mapping between claimID and messages in the AMQP 0.9
>>model, it effectively restrict consumption of messages to one per
>>claimID. This in turn prevents batch consumption benefits.
>>
>>  6.  Marconi message consumption acknowledgment requires both claimID
>>and messageID to be provided. MessageID concept is missing in AMQP 0.9.
>>In order to implement this API, assuming the artificial 1-1 restriction
>>of claim-message mapping from #5 above, this API could be implemented by
>>requiring that messageID === claimID. This is really a workaround.
>>
>
>These 2 points represent quite a change in the way Marconi works and a
>trade-off in terms of batch consumption (as you mentioned). I believe
>we can have support for both things. For example, claimID+suffix where
>suffix point to a specific claimed messages.
>
>I don't want to start an extended discussion about this here but lets
>keep in mind that we may be able to support both. I personally think
>Marconi's claim's are reasonable as they are, which means I currently
>like them better than SQS's.

What are the advantages of the Marconi model for claims over the SQS and
Azure Queue model for acknowledgements?

I think the SQS and Azure Queue model is both simpler and more flexible.
But the key advantage is that it has been around for a while, has been
proven to work, and people understand it.

1. SQS and Azure require only one concept to acknowledge a message
(receipt handle/pop receipt) as opposed to Marconi¹s two concepts (message
ID + claim ID). SQS/Azure model is simpler.

2. Similarly to Marconi, SQS and Azure allow individual claimed messages
to be deleted. This is a wash.

3. SQS and Azure allow a batch of messages *up to a particular receipt
handle/pop receit* to be deleted. This is more flexible than Marconi¹s
mechanism or deleting all messages associated with a particular claim, and
works very well for the most common scenario of in-order message delivery.

>
>>  7.  RabbitMQ message acknowledgment MUST be sent over the same AMQP
>>channel instance on which the message was originally received. This
>>requires that the two Marconi HTTP calls that receive and acknowledge a
>>message are affinitized to the same Marconi backend. It either
>>substantially complicates driver implementation (server-side reverse
>>proxing of requests) or adds new requirements onto the Marconi
>>deployment (server affinity through load balancing).
>>
>
>Nothing to do here. I guess a combination with a persistent-transport
>protocol would help but we don't want to make the store driver depend
>on the transport.

The bigger issue here is that the storage layer abstraction has been
design with a focus on a set of atomic, *independent* operations, with no
way to correlate them or share any state between them. This works well for
transport layers that are operation-centered, like HTTP. This abstraction
is likely to be insufficient when one wants to use a connection-oriented
transport (e.g. WebSocket, AMQP, MQTT), or a storage driver based on a
connection-oriented protocol (e.g. AMQP). Without explicit modeling of a
state that spans several atomic calls to the storage driver, in particular
around the lifetime of the connection, current storage abstraction cannot
satisfy these configurations well.

>Simplifying the API is definitely something the team wants to do. v2.0
>of the API seems a good target for this simplification. Lets iterate
>over the existing endpoints, write everything down on an etherpad and
>evaluate everything.
>
>One thing I do want to say is that despite Marconi being akin to SQS
>and Azure Queues, it doesn't aim to be *just* like them. Lets learn
>from their experiences and do the changes that we consider best for
>the final user.

It is perfectly valid to aspire to do something better than SQS or Azure
Queues. On the flip side there is also the cost associated with doing
things differently, introducing concepts, models, or patterns that are new
and that impose new learning on customers. Is the new thing 10x better
then the old thing? If yes, folks will learn it. If not, folks will think
twice. As I said before on IRC, I think it is fine to reinvent a wheel;
but it better be super-duper-hands-down-better wheel.

I don¹t think Marconi should "compete" with SQS or Azure. It should learn
from it by embracing its proven models and concepts. The reason I think
Marconi is interesting is that I expect it to compete with RabbitMQ,
ActiveMQ, [name-your-own]. Be 10x better by supporting *multi-tenancy* and
*HTTP*. That would be a better wheel for me.

Tomasz Janczuk
@tjanczuk
HP