Re: [openstack-dev] [marconi] RabbitMQ (AMQP 0.9) driver for Marconi
Thanks Flavio, inline. On 6/13/14, 1:37 AM, Flavio Percoco fla...@redhat.com wrote: On 11/06/14 18:01 +, Janczuk, Tomasz wrote: Thanks Flavio, some comments inline below. On 6/11/14, 5:15 AM, Flavio Percoco fla...@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. What matters is whether the listing functionality is useful or not. Lets not think about it as listing or paging but about getting batches of messages that are still available for others to process in parallel. As mentioned in my previous email, AMQP has been a good way to analyze the extra set of features Marconi exposes in the API but I don't want to make the choice of usability based on whether traditional messaging systems support it and how it could be implemented there. This functionality is very useful in a number of scenarios. It has traditionally been the domain of database systems - flexible access to data is what DBs excel in (select top 1000 * from X order by create_date). Vast majority of existing messaging systems has a much more constrained and prescriptive way of accessing data than a database. Why does this functionality need to be part of Marconi? What are the benefits of listing messages in Marconi that cannot be realized with a plain database? In other words, if I need to access my data in that way, why would I use Marconi rather than a DB? 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. TBH, I'm not exactly sure where you're going with this. I mean, the model may look simpler but it's not necessarily better nor easier to implement. Keeping both, messages and claims, separate in terms of IDs and management is flexible and powerful enough, IMHO. But I'm probably missing your point. I don't believe requiring the messageID+ClaimID to delete a specific, claimed, messages is hard. It may not be hard. It is just more complex than it needs to be to accomplish the same task. 2. Similarly to Marconi, SQS and Azure allow individual claimed messages to be deleted. This is a wash. Calling it a wash is neither helpful nor friendly. Why do you think it is a wash? Claiming a message does not delete the message, which means consumers may want to delete it before the claim is released
Re: [openstack-dev] [marconi] Reconsidering the unified API model
What exactly is the core set of functionalities Marconi expects all implementations to support? (I understand it is a subset of the HTTP APIs Marconi exposes?) On 6/12/14, 4:56 AM, Flavio Percoco fla...@redhat.com wrote: On 11/06/14 16:26 -0700, Devananda van der Veen wrote: On Tue, Jun 10, 2014 at 1:23 AM, Flavio Percoco fla...@redhat.com wrote: 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?) The OpenStack Infra team does. 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. I disagree strongly on this point. Interoperability is one of the cornerstones of OpenStack. We've had panels about it at summits. Designing an API which is not interoperable is not a fair tradeoff for performance - it's destructive to the health of the project. Where other projects have already done that, it's unfortunate, but let's not plan to make it worse. A lack of interoperability not only prevents users from migrating between clouds or running against multiple clouds concurrently, it hurts application developers who want to build on top of OpenStack because their applications become tied to specific *implementations* of OpenStack. What I meant to say is that, based on a core set of functionalities, all extra functionalities are part of the fair trade-off. It's up to the cloud provider to choose what storage driver/features they want to expose. Nonetheless, they'll all expose the same core set of functionalities. I believe this is true also for other services, which I'm not trying to use as an excuse but as a reference of what the reality of non-opinionated services is. Marconi is opinionated w.r.t the API and the core set of functionalities it wants to support. You make really good points that I agree with. Thanks for sharing. -- @flaper87 Flavio Percoco ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [marconi] performance
Hello, I was wondering if there is any update on the performance of Marconi? Are results of any performance measurements available yet? Thanks, Tomasz Janczuk @tjanczuk HP On 4/29/14, 1:01 PM, Janczuk, Tomasz tomasz.janc...@hp.com wrote: Hi Flavio, Thanks! I also added some comments to the performance test plan at https://etherpad.openstack.org/p/marconi-benchmark-plans we talked about yesterday. Thanks, Tomasz On 4/29/14, 2:52 AM, Flavio Percoco fla...@redhat.com wrote: On 28/04/14 17:41 +, Janczuk, Tomasz wrote: Hello, Have any performance numbers been published for Marconi? I have asked this question before (http://lists.openstack.org/pipermail/openstack-dev/2014-March/031004.ht m l) but there were none at that time. Hi Tomasz, Some folks in the team are dedicated to working on this and producing results asap. The details and results will be shared as soon as possible. Thanks a lot for your interest, I'll make sure you're in the loop as soon as we have them. -- @flaper87 Flavio Percoco ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [marconi] Reconsidering the unified API model
On 6/11/14, 2:43 AM, Gordon Sim g...@redhat.com wrote: On 06/10/2014 09:57 PM, Janczuk, Tomasz wrote: Using processes to isolate tenants is certainly possible. There is a range of isolation mechanisms that can be used, from VM level isolation (basically a separate deployment of the broker per-tenant), to process level isolation, to sub-process isolation. The higher the density the lower the overall marginal cost of adding a tenant to the system, and overall cost of operating it. From the cost perspective it is therefore desired to provide sub-process multi-tenancy mechanism; at the same time this is the most challenging approach. Where does the increased cost for process level isolation come from? Is it simply the extra process required (implying an eventual limit for a given VM)? With sub-process isolation you have to consider the fairness of scheduling between operations for different tenants, i.e. potentially limiting the processing done on behalf of any given tenant in a given period. You would also need to limit the memory used on behalf of any given tenant. Wouldn't you end up reinventing much of what the operating system does? Process level isolation is more costly than sub-process level isolation primarily due to larger memory consumption. For example, CGI has worse cost characteristics than FastCGI when scaled out. But the example closer to Marconi¹s use case is database systems: I can¹t put my finger on a single one that would isolate queries executed by its users using processes. Sub-process multi-tenancy is a not an easy problem, but it is not one that cannot be solved, especially in the context of a messaging system. A messaging system exposes a set of operations that is very well defined and constrained. The cost of these operations can be relatively easily assessed a priori and managed accordingly to provide a secure multi-tenant platform. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [marconi] RabbitMQ (AMQP 0.9) driver for Marconi
Thanks Flavio, some comments inline below. On 6/11/14, 5:15 AM, Flavio Percoco fla...@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
[openstack-dev] [marconi] RabbitMQ (AMQP 0.9) driver for Marconi
I the last few days I attempted to implement a RabbitMQ (AMQP 0.9) storage driver for Marconi. These are the take-aways from this experiment. High level, it showed that current Marconi APIs *cannot* be mapped onto the AMQP 0.9 abstractions. In fact, currently it is not even possible to support a subset of functionality that would allow both message publication and consumption. 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. 2. Marconi exposes HTTP APIs that allow random access to messages by ID. This API cannot be implemented on top of AMQP 0.9 which does not allow random access to messages, and the message ID concept is not present in the model. 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. 4. Marconi message publishing APIs return server-assigned message IDs. Message IDs are absent from the AMQP 0.9 model and so the result of message publication cannot provide them. 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. 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). 8. Currently Marconi does not support an HTTP API that allows a message to be consumed with immediate acknowledgement (such API is in the pipeline however). Despite the fact that such API would not even support the at-least-once guarantee, combined with the restriction from #7 it means that there is simply *no way* currently for a RabbitMQ based driver to implement any form of message consumption using today’s HTTP API. If Marconi aspires to support a range of implementation choices for the HTTP APIs it prescribes, the HTTP APIs will likely need to be re-factored and simplified. Key issues are related to the APIs that allow messages to be looked up without consuming them, the explicit modeling of message IDs (unnecessary in systems with strict queuing semantics), and the acknowledgment (claim) model that is different from most acknowledgments models out there (SQS, Azure Queues, AMQP). I believe Marconi would benefit from a small set of core HTTP APIs that reflect a strict messaging semantics, providing a scenario parity with SQS or Azure Storage Queues. Thanks, Tomasz Janczuk @tjanczuk HP ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [marconi] Reconsidering the unified API model
Using processes to isolate tenants is certainly possible. There is a range of isolation mechanisms that can be used, from VM level isolation (basically a separate deployment of the broker per-tenant), to process level isolation, to sub-process isolation. The higher the density the lower the overall marginal cost of adding a tenant to the system, and overall cost of operating it. From the cost perspective it is therefore desired to provide sub-process multi-tenancy mechanism; at the same time this is the most challenging approach. On 6/10/14, 1:39 PM, Gordon Sim g...@redhat.com wrote: On 06/10/2014 06:33 PM, Janczuk, Tomasz wrote: From my perspective the key promise of Marconi is to provide a *multi-tenant*,*HTTP* based queuing system. Think an OpenStack equivalent of SQS or Azure Storage Queues. As far as I know there are no off-the-shelve message brokers out these that fit that bill. Indeed. The brokers I'm familiar with don't have multi-tenancy built into them. But rather than have one broker process support multiple tenants, wouldn't it be possible to just have separate processes (even separate containers) for each tenant? Note that when I say ³multi-tenant² I don¹t mean just having multi-tenancy concept reflected in the APIs. The key aspect of the multi-tenancy is security hardening against a variety of attacks absent in single-tenant broker deployments. For example, an authenticated DOS attack. Understood, ensuring that one tenant is completely isolated from being impacted by anything another tenant might try to do. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [marconi] Reconsidering the unified API model
I could not agree more with the need to re-think Marconi’s current approach to scenario breadth and implementation extensibility/flexibility. The broader the HTTP API surface area, the more limited are the implementation choices, and the harder are performance trade-offs. Current HTTP APIs of Marconi have a large surface area that aspires to serve too many purposes. It seriously limits implementation choices. For example, one cannot fully map Marconi’s HTTP APIs onto an AMQP messaging model (I tried last week to write a RabbitMQ plug-in for Marconi with miserable results). I strongly believe Marconi would benefit from a very small HTTP API surface that targets queue based messaging semantics. Queue based messaging is a well understood and accepted messaging model with a lot of proven prior art and customer demand from SQS, to Azure Storage Queues, to IronMQ, etc. While other messaging patterns certainly exist, they are niche compared to the basic, queue based, publish/consume pattern. If Marconi aspires to support non-queue messaging patterns, it should be done in an optional way (with a “MAY” in the HTTP API spec, which corresponds to option A below), or as a separate project (option B). Regardless the choice, the key to success is in in keeping the “MUST” HTTP API endpoints of Marconi limited in scope to the strict queue based messaging semantics. I would be very interested in helping to flesh out such minimalistic HTTP surface area. Thanks, Tomasz Janczuk @tjanczuk HP From: Kurt Griffiths kurt.griffi...@rackspace.commailto:kurt.griffi...@rackspace.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Mon, 9 Jun 2014 19:31:03 + To: OpenStack Dev openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: [openstack-dev] [marconi] Reconsidering the unified API model 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 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?) 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) Option C. Require every backend to support the entirety of the API as it now stands. For: * Least disruptive in terms of the current API design and implementation * Affords a wider variety of messaging patterns (counter: YAGNI?) * Reuses code in
Re: [openstack-dev] [marconi] Removing Get and Delete Messages by ID
First of all, I think the removal of ³get message[s] by ID² is a great change, it moves Marconi APIs closer to a typical messaging semantics. However, I still see the ³list messages² API in the spec (https://wiki.openstack.org/wiki/Marconi/specs/api/v1.1#List_Messages). Is it the plan to leave this API in, or is it also going to be removed? If the motivation for removing the ³get message[s] by ID² was to make it easier to support different store backends (e.g. AMQP), I would expect the same argument to apply to the ³list messages² API which allows random access to messages in a queue. Regarding deleting claimed messages, I think it should be possible to claim multiple messages but then delete any of them individually. For reference, that is the semantics of a ³batch claim² that SQS, Azure, and IronMQ have - during batch claim a number of messages can be claimed, but each of them is assigned a unique ³token² than can later be used to delete just that message. I believe there is a good reason it is organized that way: even if a batch of messages is claimed, their processing can be completely unrelated, and executed in different time frames. It does not make sense to make logical completion of message A conditional on the success of processing of message B within a batch. It also does not make sense to hold up completion of all messages in a batch until the completion of the message that takes most time to process. Put it another way, a batch is merely an optimization over the atomic operation of claiming and deleting a single message. The optimization can allow multiple messages to be claimed at once; it can also allow multiple messages to be deleted at once (I believe AMQP has that semantics); but it should not prevent the basic use case of claiming or deleting of a single message. On 5/29/14, 1:22 AM, Flavio Percoco fla...@redhat.com wrote: On 28/05/14 17:01 +, Kurt Griffiths wrote: Crew, as discussed in the last team meeting, I have updated the API v1.1 spec to remove the ability to get one or more messages by ID. This was done to remove unnecessary complexity from the API, and to make it easier to support different types of message store backends. However, this now leaves us with asymmetric semantics. On the one hand, we do not allow retrieving messages by ID, but we still support deleting them by ID. It seems to me that deleting a message only makes sense in the context of a claim or pop operation. In the case of a pop, the message is already deleted by the time the client receives it, so I don¹t see a need for including a message ID in the response. When claiming a batch of messages, however, the client still needs some way to delete each message after processing it. In this case, we either need to allow the client to delete an entire batch of messages using the claim ID, or we still need individual message IDs (hrefs) that can be DELETEd. Deleting a batch of messages can be accomplished in V1.0 using ³delete multiple messages by ID². Regardless of how it is done, I¹ve been wondering if it is actually an anti-pattern; if a worker crashes after processing N messages, but before deleting those same N messages, the system is left with several messages that another worker will pick up and potentially reprocess, although the work has already been done. If the work is idempotent, this isn¹t a big deal. Otherwise, the client will have to have a way to check whether a message has already been processed, ignoring it if it has. But whether it is 1 message or N messages left in a bad state by the first worker, the other worker has to follow the same logic, so perhaps it would make sense after all to simply allow deleting entire batches of claimed messages by claim ID, and not worrying about providing individual message hrefs/IDs for deletion. There are some risks related to claiming a set of messages and process them in batch rather than processing 1 message at a time. However, some of those risks are valid for both scenarios. For instance, if a worker claims just 1 message and dies before deleting it, the server will be left with an already processed message. I believe this is very specific to the each use-case. Based on their needs, users will have to choose between 'pop'ng' messages out of the queue or caliming them. One way to provide more info to the user is by keeping track of how many times (or even the last time) a message has been claimed. I'm not a big fan of this because it'll add more complexity and more importantly we won't be able to support this on the AMQP driver. It's common to have this kind of 'tolerance' implemented in the client-side. The server must guarantee the delivery mechanism whereas the client must be tolerant enough based on the use-case. With all this in mind, I¹m starting to wonder if I should revert my changes to the spec, and wait to address these changes in the v2.0 API, since it seems that to do this right, we need to make some changes that are anything but
Re: [openstack-dev] [Marconi] Kafka support and high throughput
Keith, Have you put HTTP protocol in front of Kafka, or are you using Kafka¹s native protocol? Can you also expand a little on your performance requirements? What does ³high throughput² mean to you in terms of the messaging patterns (# of producers and consumers, # of queues and queue partitions, message size, desired throughput)? Thanks, Tomasz Janczuk @tjanczuk HP On 5/31/14, 11:56 PM, Flavio Percoco fla...@redhat.com wrote: On 30/05/14 06:03 -0700, Keith Newstadt wrote: Has anyone given thought to using Kafka to back Marconi? And has there been discussion about adding high throughput APIs to Marconi. We're looking at providing Kafka as a messaging service for our customers, in a scenario where throughput is a priority. We've had good luck using both streaming HTTP interfaces and long poll interfaces to get high throughput for other web services we've built. Would this use case be appropriate in the context of the Marconi roadmap? Hi, Kafka would be a good store to back Marconi with. We've had some feedback from the community w.r.t Kafka and there seems to be lot of interest on it. The team is not currently targeting it but we could probably do something after the J release. That said, Marconi's plugin architecture allows people to create third-party drivers and obviously use them. It'd be really nice to see some work going on that area as an external driver. Thanks, Flavio -- @flaper87 Flavio Percoco ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [heat] How to cross-reference resources within OS::Heat::ResourceGroup
I am trying to create an OS::Heat::ResourceGroup of VMs and assign each VM a
floating IP. As far as I know this requires cross-referencing the VM, port, and
floating IP resources. How can I do that within a OS::Heat::ResourceGroup
definition?
The `port: { get_resource: vm_cluster.vm_port.0 }` below is rejected by Heat.
Any help appreciated.
Thanks,
Tomasz
vm_cluster:
type: OS::Heat::ResourceGroup
properties:
count: { get_param: num_instances }
resource_def:
vm:
type: OS::Nova::Server
properties:
key_name: { get_param: key_name }
flavor: { get_param: flavor }
image: { get_param: image }
networks:
- port: { get_resource: vm_cluster.vm_port.0 }
vm_port:
type: OS::Neutron::Port
properties:
network_id: { get_param: private_net_id }
fixed_ips:
- subnet_id: { get_param: private_subnet_id }
security_groups: [{ get_resource: rabbit_security_group }]
vm_floating_ip:
type: OS::Neutron::FloatingIP
properties:
floating_network_id: { get_param: public_net_id }
port_id: { get_resource: vm_cluster.vm_port.0 }
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] How to cross-reference resources within OS::Heat::ResourceGroup
Could this be accomplished with 3 resource groups instead of one? The
first would create the ports, the second floating IPs, and the last the
VMs? In that case, would there be a way to construct a reference to a
particular instance of, say, a port, when creating an instance of a
floating IP?
On 5/6/14, 12:41 PM, Randall Burt randall.b...@rackspace.com wrote:
A resource group's definition contains only one resource and you seem to
want groups of multiple resources. You would need to use a nested stack
or provider template to do what you're proposing.
On May 6, 2014, at 2:23 PM, Janczuk, Tomasz tomasz.janc...@hp.com
wrote:
I am trying to create an OS::Heat::ResourceGroup of VMs and assign each
VM a floating IP. As far as I know this requires cross-referencing the
VM, port, and floating IP resources. How can I do that within a
OS::Heat::ResourceGroup definition?
The `port: { get_resource: vm_cluster.vm_port.0 }` below is rejected by
Heat.
Any help appreciated.
Thanks,
Tomasz
vm_cluster:
type: OS::Heat::ResourceGroup
properties:
count: { get_param: num_instances }
resource_def:
vm:
type: OS::Nova::Server
properties:
key_name: { get_param: key_name }
flavor: { get_param: flavor }
image: { get_param: image }
networks:
- port: { get_resource: vm_cluster.vm_port.0 }
vm_port:
type: OS::Neutron::Port
properties:
network_id: { get_param: private_net_id }
fixed_ips:
- subnet_id: { get_param: private_subnet_id }
security_groups: [{ get_resource: rabbit_security_group }]
vm_floating_ip:
type: OS::Neutron::FloatingIP
properties:
floating_network_id: { get_param: public_net_id }
port_id: { get_resource: vm_cluster.vm_port.0 }
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [marconi] performance
Hi Flavio, Thanks! I also added some comments to the performance test plan at https://etherpad.openstack.org/p/marconi-benchmark-plans we talked about yesterday. Thanks, Tomasz On 4/29/14, 2:52 AM, Flavio Percoco fla...@redhat.com wrote: On 28/04/14 17:41 +, Janczuk, Tomasz wrote: Hello, Have any performance numbers been published for Marconi? I have asked this question before (http://lists.openstack.org/pipermail/openstack-dev/2014-March/031004.htm l) but there were none at that time. Hi Tomasz, Some folks in the team are dedicated to working on this and producing results asap. The details and results will be shared as soon as possible. Thanks a lot for your interest, I'll make sure you're in the loop as soon as we have them. -- @flaper87 Flavio Percoco ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [marconi] performance
Hello, Have any performance numbers been published for Marconi? I have asked this question before (http://lists.openstack.org/pipermail/openstack-dev/2014-March/031004.html) but there were none at that time. Thanks, Tomasz Janczuk ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
