 Okay everybody, welcome to track 2. We have Phelon Wang here, a core contributor to OpenStack Glance and Zacure Message Service who's going to talk to us about Zacure Message. Thank you. Good morning everyone, I'm very pleased to introduce Zacure with you guys. So first, happy Father's Day. Or I shall introduce introduction for myself. I'm very proud to be a catalyst between OpenStack and customer because I'm from Catalyst, Catalyst IT. I'm a full-time OpenStack developer. Daily I just focus on Glance and Zacure but I also need to take care about all the components we are running in our public cloud using the iName bug. So you will see I also contribute NOAA, Neutron, Ceilometer, all of them are OpenStack components. And why am I here? Firstly, I like sharing and secondly, Docker is good. And I like sharing, good stuff. So where are you here? You are a developer. So as a developer you may want to use messaging service to distribute your application. And the second reason maybe you are an operator or advocate may want to adopt messaging service like Zacure in your production system. And maybe you are just lost to find the track one rule. Okay, the agenda for this session. So what is it not Zacure and what it is? Why Zacure? And the overview architecture of Zacure. And a basic overview for the rest of the API of Zacure. And some user case of Zacure. Okay, so what's in a name? Zacure, in my so potemming methodology, Zacure is a messenger of the Gaussian. And he relates the message to mantles through his power over their dreams and net mails. And before Zacure we use Makoni. Makoni is a former name if you just Google you will see a lot of, yeah, results of Makoni. But there are some trademark problem. Like, you know, the development cases in Oppositec is quantum to Neutron. So we also ran into the same problem. So we just renamed it from Makoni to Zacure. Makoni is an Italian inventor, often credit with the invention of radio. So I really like Makoni. But yeah, for now we're using Zacure. So what is now? So firstly, Zacure is not a replacement of Rabium Q, QP, or theorem Q. So initially, when we announced Zacure in Oppositec community, there are lots of questions. And the first question is why you guys just want to use, you know, announce Makoni, Zacure to maybe you want to replace the message Q using in Oppositec, like Rabium Q or QP. Actually, that's not the case we want to resolve. And we're not curing service, I would say, animal. Initially based on the initial design, you know, our statement for Zacure is we are curing and messaging service. But for now, we are just focusing on the messaging service. And it is not a mail service, even though we can send notification by webhook or by email. So basically Makoni is a messaging service, just messaging service. And a two topic, sorry, two type code use case just request response and publish subscription. So what is Zacure? Basically, Zacure is a multi-tenant messaging service with the support for multi backend and the protocols. For now, we can support MongoDB and Redis as a storage backend. And we can also support Whiskey, HTTP and WebSocket as a transport layer. So why Zacure? So that's the reaction, you know, many guys when they first hear about Zacure, they will say, what, you guys want to just create another real for messaging service? Actually, not. So if you can't really understand, you know, what Zacure is doing, you can just raffle in the SQS of AWS. SQS is simple queue service of AWS. And AWS also has another service named SNS, simple notification service. So basically, Zacure is trying to resolve the same problem like SQS and SNS, but it's open source. So why Zacure? So firstly, Zacure is open source and is, you know, as a big tent of open stack. And it's easy to use, sorry, it's a typo. And it's scalable for easy. And it can be extensible at the storage layer and the transport layer. So why Zacure instead of something like SQS? Like I mentioned, SQS is not open source. So that means you can't run your own instance in your system. And why not Rabi MQ, 0MQ? Yes, you can. You can run Rabi MQ, 0MQ in your system. But that means you have to, you know, how to handle or take care about the HA, deployment, scaling, maintenance. But if you have, you know, message stories like Zacure, you just use it. So here is a message queue comparison plug from, I don't know, Steve. He has some comparison between Makoni, but at this stage it's named Makoni. Zacure and SQS and Iron MQ, Storm MQ, and software message queue. And the result, so basically here is the aspects he's carrying about. So the central connection point, file points, and first in, first out support. And delivery to the first available consumer, basic publish, subscribe support, and push message support. So finally, you can see, we can have a quick look for the result. SQS got 8. Iron MQ got 12. Storm got, sorry, 0. Softlayer got 7. Actually Makoni got 12, but because there is a penalty for needing SQS software, there is a minus file, but I would argue it is not really true. Because for Zacure, you can just deploy it without any other OpenStack components. So I'm not sure if the guy understand the requirements for Zacure, but I would say for Zacure, you can, if you want to leverage the authentication system for OpenStack, maybe you need also deploy Kistone. Kistone is an authentication service of OpenStack. Otherwise, if you just want to use Zacure, you don't need any other OpenStack components. You can just deploy Zacure. So hopefully, that blog can give you a basic understanding for Zacure. And what is the advanced feature we are providing? So firstly, we can support horizontally scalable, and we can support message delivery guaranteed. It depends on the backend storage. And we can also support notifications. For notifications, for now, we support Webhook and email. And Zacure is very operation friendly. We have two recipe endpoints. One is ping. Ping means you can access the ping endpoints. It will return 204 if Zacure is running very well. I'll just return 503. Maybe there are some, sorry, wrong error. And you can just use another more detailed endpoint named health. Health, we will return a lot of information about, like, if the server is reachable for each action, for example, for create a queue, delete a queue, post a message, how many times it will need, based on current, you know, the system status. So it's very, very helpful for the operator. And the architecture. So this is a basic architecture of Zacure. So you can see for now we have two layers. The first layer is the storage layer. For now, we can support MongoDB driver and Redis driver as the storage backend. And as a storage layer, actually, we have two layers because we can support pools. For pools means you can create one pool just for MongoDB. And you can create another pool for Redis. And we have another, like, abstract layer that is a control plane. So when you create a queue, the control plane will decide which pool you can use. For example, you can give the pool a weight. A higher weight will be picked first. And for now, at the control plane layer, I mean, the management layer, we can support MongoDB driver, Circle Alchemy driver, and Redis driver. And for the transport layer, now there are two drivers. One is HTTP and the other one is WebSocket. So it's very friendly for the WebSocket. It's very friendly for those, you know, the APP application developers. And about that, you can deploy HAProxy or load balancer and rate limiter in front of the Zacure service. And before that, just the client, the client to access Zacure service. So the architecture, the architecture basically, like I mentioned about just transport and storage. So it's very, very lightweight. And as a transport, we support HTTP WebSocket. Storage is MongoDB and Redis. So the REST API, now we have three types, REST API. So the first type is the public API. Public API means all the under-users can access the public API. And for the admin API means they only can be accessed by the administrator or operators. And the operation API. So for the public API is very, very stressful. You can see we have messages, so you can just post messages for Q or just get message, delete message. And we also support subscriptions. Subscriptions means you can subscribe Q. And when there is a message post for the Q, the subscriber of the Q will be notified. So for this, it basically can match the same function of AWS, SNS. So that basically means we are using one service to cover the post use case of SQIs and SNS. So we didn't create two service. So there are some two endpoints. And claims, claims means you can claim some messages. Claims means if the message is claimed, then there is no other worker. Can use, can consume the message. And Qs. So like I mentioned about, initially Q is the first class system in the Docker world. But for now, Q is not really necessary. Because if you just post message to a Q and the Q doesn't exist, we can create this lazy. So it's not really necessary. You can just focus on message. And admin API. So for admin API, there are two endpoints. The first one is pools. Like I mentioned, for pool, you can just easily get the horizontally scalable. So you can create many pools. And you can just give a wait for the pool. So there is a simple algorithm to schedule the request for the Q to the right pool. And the flavors. Flavors means you can define some flavor based on the capability of the pool. For example, you can define a fast storage pool. And you can define a durable storage pool. So when you define a flavor, for example, I just define, as an admin, I just define a fast storage pool based on, for example, Redis. So as an end user, then I can create a new Q based on the flavor. Because I just want to use the fast storage. Just care about the performance. So you can create a Q based on the flavor. And the operation API. Operation API, yeah, like I mentioned, we can support PIN and health. PIN is very simple. But for health, we can support very detailed status of the, you know, the stacker stories. For example, you can see if the storage is reachable. Now I have two pools. The first pool is for Redis. And you can see it will give the status when, you know, how many times to post message, how many times, I mean, you need to consume to delete message, delete Q, and it will return all the pools you're using in your Docker service. And also if the catalog, catalog actually is the control plane, is reachable or not. So it's very, very useful for the operators. Okay, the use case. So like I mentioned, the use case of Zacher is trying to resolve is the first one is messaging. So Zacher is a messaging service for sure. And notifications. For notification, in this release, we just support email as a, email as a notification. And we support Webhook in the progress release. And in the cloud. In the cloud means the other components of the cloud can consume the messaging service. For now, heat, heat is Augustation service of OpenStack is trying integrate with Zacher and Swift. Swift is the object storage of OpenStack is also trying to leverage Docker as a notification middleware. And the user facing. There are some discussion in OpenStack community trying to use Zacher to send some task status to end user, to the end user of the cloud. This is another use case. So for now, a lab demo. I would like to give us a lab demo of Zacher. So firstly, if you, if you want to use the notification, you will need a queue. If you don't care about navigation, you actually don't have to create a queue. But for now, I want to demo the notification. So I need to create a queue. So just, okay. If the queue is created successfully, it will just return 201. And for now, we need to create a subscription. So the subscriptions post model is very simple. You just need to specify the subscriber. But now I just want to demo the, the web socket. This is the TTL options. Yeah. So we just create a subscription for the new queue. And we can look in for some messages. Just post those messages. And you will see I'm running a local simple server. This is the message. The notification, the message, when you post the messages, the message will be saved in the backend, started backend. And meanwhile, the message will be sent to the subscriber. So for now, I just use a web hook subscriber. So the web hook is just a simple web server, HSP server running in local. So you can see the web server just received the message from Zucker. Yeah, that's it. And here is Github location of Zucker. So you can just access in Github. So still don't ask me too hard questions. So we've got time for just a couple of questions. Is it hard? So one big potential of something like Zucker is that we can stop polling for things happening in our cloud. With the web socket endpoint, it's great that we can just, you know, block on it and wait for something to happen and then pick that up and do it immediately. But is the implementation just pushing the polling further down or can it be event driven all the way from the bottom? You mean the web socket or the notification web hook support? Just the whatever mechanism there is to get messages without constantly polling. Actually, if you just use the notifications, that means you don't need to okay. I'm afraid we're out of time. So if you could join me in thanking Phaelong once more for that talk. Thank you.