[openstack-dev] [zaqar] Summary of Barcelona Design Summit

Fei Long Wang feilong at catalyst.net.nz
Thu Nov 3 18:10:30 UTC 2016


Firstly, thank you for everyone joined Zaqar sessions at Barcelona 
summit. We definitely made some great progress for those working 
sessions. Here are the high level summary and those are basically our 
Ocata priorities. I may miss something so please feel free to 
comment/reply this mail.

Performance matters

We got some interests last cycle about deploying Zaqar as messaging 
service in public/private cloud. And performance is one of popular 
questions. Though we have a built-in benchmark tool, there is no way to 
diagnose when the performance can't the meet user's exception in a given 
deployed environment. Besides, there is no good way to grantee a new 
patch won't impact the performance. Hence we discussed this topic in summit.

For the first issue, the solution is osprofiler. The patches are already 
there[1], we just need some review and it would be great if we can merge 
them in Ocata-1.

For the second issue, we would like to introduce a new gate job which 
based on our built-in benchmark tool. The idea is comparing the 
performance before/after current patch.

Subscription confirmation

Xiyuan Wang and Hao Wang did a great job in last cycle about 
subscription confirmation. As a result, we have merged the webhook 
confirmation patches. In the design session, we reviewed the design of 
email part, which changed the original design a bit about how to set the 
external URL for confirmation page.

Swift storage driver

Based on current design, Zaqar relays on under layer storage backend to 
get the stability and scalability. For example, if you're using MongoDB, 
you have to enable the replicaset to get replicating messages. Since 
Swift has the native support of replication and it's deployment for most 
of the OpenStack environment. So it's would be great if Zaqar can 
support using Swift as the storage backend driver.

Purge queue

It's not a new blueprint but seems it's a good time to pick since we do 
have some users asking it. And the conclusion in the session is, the 
feature is safe and good to have. A spec will be posed soon which will 
mainly discuss what the API looks like and how to design it to avoid 
race condition issue.

Notification delivery policy

We didn't touch this topic due a stranger in this session. See below for 
more details.

Interest for real deployment

A cloud architect from Mirantis joined our design session to discuss 
about using Zaqar as the messaging queue service for their customer. In 
their requirement, purge queue and dead letter queue are on the list 
which are also on our road map. And we had a great discussion about the 
deployment architecture, especially how to get a great scalability.

Please contribute this thread to fill the points/things I missed or pop 
up in #openstack-zaqar channel directly with questions and suggestions.

[1] https://review.openstack.org/141356

Cheers & Best regards,
Fei Long Wang (王飞龙)
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flwang at catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington

More information about the OpenStack-dev mailing list