On 09/06/14 19:31 +0000, Kurt Griffiths wrote:
Folks, this may be a bit of a bombshell, but I think we have been dancing around the issue for a while now and we need to address it head on. Let me start with some background.Back when we started designing the Marconi API, we knew that we wanted to support several messaging patterns. We could do that using a unified queue resource, combining both task distribution and feed semantics. Or we could create disjoint resources in the API, or even create two separate services altogether, one each for the two semantic groups. The decision was made to go with a unified API for these reasons: • It would afford hybrid patterns, such as auditing or diagnosing a task distribution queue • Once you implement guaranteed delivery for a message feed over HTTP, implementing task distribution is a relatively straightforward addition. If you want both types of semantics, you don’t necessarily gain anything by implementing them separately. Lately we have been talking about writing drivers for traditional message brokers that will not be able to support the message feeds part of the API. I’ve started to think that having a huge part of the API that may or may not “work”, depending on how Marconi is deployed, is not a good story for users,esp. in light of the push to make different clouds more interoperable.Therefore, I think we have a very big decision to make here as a team and a community. I see three options right now. I’ve listed several—but by no means conclusive—pros and cons for each, as well as some counterpoints, based on past discussions. Option A. Allow drivers to only implement part of the API For: • Allows for a wider variety of backends. (counter: may create subtle differences in behavior between deployments) • May provide opportunities for tuning deployments for specific workloads
* Simplifies client implementation and API
Against: • Makes it hard for users to create applications that work across multiple clouds, since critical functionality may or may not be available in a given deployment. (counter: how many users need cross-cloud compatibility? Can they degrade gracefully?)
This is definitely unfortunate but I believe it's a fair trade-off. I believe the same happens in other services that have support for different drivers. We said we'd come up with a set of features that we considered core for Marconi and that based on that we'd evaluate everything. Victoria has been doing a great job with identifying what endpoints can/cannot be supported by AMQP brokers. I believe this is a key thing to have before we make any decision here.
Option B. Split the service in two. Different APIs, different services. One would be message feeds, while the other would be something akin to Amazon’s SQS. For: • Same as Option A, plus creates a clean line of functionality for deployment (deploy one service or the other, or both, with clear expectations of what messaging patterns are supported in any case). Against: • Removes support for hybrid messaging patterns (counter: how useful are such patterns in the first place?) • Operators now have two services to deploy and support, rather than just one (counter: can scale them independently, perhaps leading to gains in efficiency)
Strong -1 for having 2 separate services. IMHO, this would just complicate things from a admin / user perspective.
Option C. Require every backend to support the entirety of the API as it nowstands.For: • Least disruptive in terms of the current API design and implementation • Affords a wider variety of messaging patterns (counter: YAGNI?) • Reuses code in drivers and API between feed and task distribution operations (counter: there may be ways to continue sharing some code if the API is split) Against: • Requires operators to deploy a NoSQL cluster (counter: many operators are comfortable with NoSQL today) • Currently requires MongoDB, which is AGPL (counter: a Redis driver is under development) • A unified API is hard to tune for performance (counter: Redis driver should be able to handle high-throughput use cases, TBD)
A and C are both reasonable solutions. I personally prefer A with a set of optional features well defined. In addition to that, we have discussed having features discoverability that will allow users to know features are supported. This makes developing applications on top of Marconi a bit harder, though. That said, I believe what needs to be done is re-think some of the existing endpoints in order to embrace existing technologies / protocols. With the addition of flavors, we'll have the same issue. For instance, a user with 2 queues on different storage drivers - 1 on mongodb and 1 on say rabbitmq - will likely have to develop based on the features exposed by the driver with less supported features - unless the application is segmented. In other words, the user won't be able to dynamically create queue instances and re-use the same code. Our API, as-is, is quite dependant on a store-forward message delivery model and on a database-like storage. I don't think this is entirely wrong but I do believe it could be simplified in order to support other drivers without splitting it.
I’d love to get everyone’s thoughts on these options; let's brainstorm for a bit, then we can home in on the option that makes the most sense. We may need to do some POCs or experiments to get enough information to make a good decision.
I think Victoria's work - AMQP 1.0 driver - is important for this decision. Lets work with her on what she's achieved and what won't be supported. We should come back here with that sub set of features considered core. Flavio -- @flaper87 Flavio Percoco
pgp71RUP6R5vZ.pgp
Description: PGP signature
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
