Greetings,
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: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
--------------------------------------------------------------------------
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
