 Hello everyone, thanks for joining us, you know, it's a very, very late session. So I just wanted to double check you guys are in the right session, yeah, because I assume most of you guys should be for shopping and just look around and you know. So what we are going to talk is Docker and yeah, so this is for the project overview and update but based on the last release for Alcata and current pack release and maybe cover a little bit Queens. So just in case if you are not really familiar what is Docker does. So Docker is a machine service and you can reference like SQL service and SNS service in AWS and you may also ask what is the relationship between Rabi MQ and Docker. I will say I was asked that question many, many, many times so they are totally different because generally as a tenant user you can deploy your own Rabi MQ cluster, that's for sure. But the problem is you have to maintain the cluster for high availability because if you are running a production and using Q service, you don't want to see the cluster is die, you don't want to lose any message, right? So the pain is you have to maintain the cluster but if you are using a messaging service like Docker or even SQL, you don't have to worry about the service, you just need to post messages to the queue and post the message from the queue. You don't have to maintain the cluster, that's totally different. So Docker is a, you know, is a messaging service in OpenStack world as mentioned just like SQLS and for now we are providing HTTP transport and also you can use WebSocket as well for better performance. So when we see the user, the users of Docker is like the tenant user of OpenStack but currently what we are seeing is more and more OpenStack product want to integrate with Docker so that, so for that case, Docker is most like infrastructure service just like Neutron and NOAA. It's not really the original goal of Docker but it's happening. For example, we are getting a requirement from some companies like Telecom companies. The customer would like to get the resource chain notifications from the OpenStack infrastructure but currently there is no way for OpenStack to get the notifications from the RAMMQ of the end layer infrastructure, right? Because you don't have the permission. It belongs to the cloud provider. So what we are trying to do is we would like to provide a way to forward the notifications from either a search light or a cylinder to Docker and in Docker because Docker is a multi-tenant messaging service so those messages can be forwarded by the third party search light or a cylinder to Docker and you can see as the tenant user, you can see the notifications from, it's happening from your resources. So is there any question? No, okay. So the background, the background of Zakra is very interesting actually. It's founded in Grizzly and in last release we have 38 contributors. Not too much but we are still alive. And now there are 40% clouds in production, no test of face. I know Rackspace is running Zakra as a messaging service but I would say they are using a very old version. It's not really active but for us, we are hosting a public cloud based in New Zealand and using OpenStack. We would like to use Zakra as a messaging service because we do have some requirements from our customers and there are about 21% of users indicated they would like to use Zakra. We just had some discussion recently, not recently actually always about the position of Zakra because what we can see is most of the departments of OpenStack is private cloud. For public cloud there are in Europe, in US, in New Zealand, in China but not too much I would say. So in private cloud the requirement for messaging queue is not really strong I would say because most of the customers running private cloud is most likely just from the virtualization plus to a cloud and they are still running some legacy application on the private cloud. So the problem is when I say legacy application that means those applications are not really distributed. So if the application is not really distributed that basically means there's not really strong requirement for the messaging queue. I think that's why there are not too much adoption for Docker until now. But we can see more and more public cloud using OpenStack. So hopefully we can get more adoption in the future. And I would say in the OpenStack world you don't have another good choice. If you would like to use Zakra and you are interested in Zakra please come to talk with us and we can maybe yeah to make it better. So here are some features and enhancements we have done in Alcatra release because I mentioned this because actually this page it is a template but this page is not in the original template but because we are transitioning from the traditional OpenStack design submit to PTG plus submit. So I think it would be nice to mention some features we have done in Alcatra so that you can get some more clear ideas. So we start Alcatra we can support Swift as a message store. So in case you don't really understand what's a message store I just give it a quick briefly introduction. So in Docker we only have two layers. One layer is the transport layer. So for transport layer as I mentioned we can use HTTP, it's Whiskey and WebSocket. And for the database layer, for the storage layer we have management store and message store. So for management store, management store will maintain Pools. For Pools actually HPools is a message store so that you can install your message into different Pools based on the weight you set for the message store so that you can get a horizontal scaling. So why I see the support for Swift is very important is just because with that way you don't have to deploy a separated MongoDB cluster. For us, Catalyst Cloud we tried to deploy it last year. But our ops are not really happy to deploy another Mongo cluster because we have planned to switch from Scylometer to Nokia. And that means we will release three MongoDB nodes because yeah with Nokia you may use Scylometer or Swift as a banking. So they just said ah, let's wait because I don't want to deploy another MongoDB cluster because I would like to wait until we release the current MongoDB. So we have said okay. So we Swift because I think most of the cloud providers have deployed Swift so you can just use Swift and with Swift you can have the built-in geography replicate. So your message is very reliable as a case. And we also supported circular equity migration but that migration is only for the management layer. As I mentioned for storage layer we have management store and message store. So for that case, yeah, it's an ugly technology depth but we just fixed it. And we also support OS profiler. I know I think in Alcata or Newton, Horizon also done that work to support a profiler panel. I think it's very important for either private cloud or public cloud because we do really care about its performance. So with OS profiler you can see the figure out the bottleneck of your Zaka server. Okay, so the new feature and enhancement we would like to do for PEC. So the first one is the service queue. As I mentioned with service queue you can forward the notifications is happening in your infrastructure, Ruby MQ cluster to your tenant user. It's a very useful feature because, yeah, you can imagine currently there is no way to get the notifications from your end layer infrastructure. And the dead letter queue. Dead letter queue will storing those messages for developers to look for some common patterns of the potential software problem. To be more clear, if a message in Zaka has been claimed maybe depending on the claim count you are citing, maybe for example three, if it has been claimed three times and still hasn't been deleted, then it could be a dead letter. So we can just forward, just move those messages to the dead letter queue to the end of future the developers can take a look at what happened. And another feature we like to do is notification delivery policy. So in Zaka, Zaka is actually like a combination of SQS and SNS. So that means you can create some notification, sorry, you can create some subscriptions on a queue so that when there is a message posted to your queue, your subscriber will be notified. So for that case, currently we can support email as a subscriber and HTTP and either HTTPS. And we can also support trust. So in OpenStack, you can use trust to get rid of the authentication problem. This is a very good feature. And so what is the notification delivery policy means? It means when you try to post the message to the subscriber, you could be failed. So with the delivery policy, you can set some retry policy. For example, the retry after three seconds or 30 seconds, I will try again to send the message or something like that. So to make sure you can forward, notify your subscriber successfully. Okay. Any question? Okay. Here is the focus for Zaka impact release. So the major focus is scalability. That's for sure because we are a messaging service and we really care about the performance. And the user experience. So for user experience, currently we are working very hard for the Docker UI. So currently in the Docker UI, you can create a queue. You can update the queue. You can update the metadata of the queue. And you can create a subscriber, subscriptions on the queue. And you can even do some basic tasks like post and get messages from the queue. And we can also create a pool on the horizon panel. Like I mentioned, a pool is actually a message store. So you can, based on the latest version, you can create a swift pool if you're not really care about the performance. Because you can expect the performance of swift driver could be slow than the Mongol driver and the Redis driver. Because each request and response when you talk to a swift is by HTTP. It could be slow. And in the future, we may create a middleware in Swift so that you can post multiple messages for Swift. Because currently Swift doesn't really support that. And we can also support create the pool flavors. I won't touch the details, but just in case. Any questions? No? Okay. For the Queen's release, we will still focus on the scalability and recentity and user experience. Actually, I mentioned that in my self-nomination for the PTA of Docker for this release, for PAC. Actually, in Docker, we only care about three indicators. The first one is the latency. The latency means when you post the messages to a queue, how long it will take. And when you claim a message, how long it will take. And another one is the scalability. Scalability means, in Zuckrade means, if I have a lot of queues, I have a lot of messages in the queue. I can get a reasonable response time no matter how much of you have the queue in your Zuckrade server and how many messages in your queue. So another one is the stability. So those three indicators are interop, actually, conflict with each other. For example, if you want to get short latency, but you may lose some scalability or reliability. So we're still working very hard to make a balance. So that is the hard part. Okay. The possible features and enhancements for queues could be quota. Actually, quota is a tricky thing in messaging service because sometimes you don't want to limit your customer for messaging. For example, in AWS, you can have about 120,000 active messages in your queue. That is a quota. But for PubSub service of Google, you won't have such kind of quota. You just have the rate limit. So it could be tricky. But what we would like to do is maybe a similar quota just like AWS for the SQS. But it depends on the setting. And we may do some work to get a better performance for sleep driver because we think it's a very good driver for most of the potential deployers. And we will also remove the pull group. Pull group is another legacy concept in Docker. And a pull group basically like you can make a lot of pull message store as a group. So with that one, you can map that group to a flavor. But actually the flavor to a pull group is a one-way mapping. It not really makes sense. So we may remove that one. Okay. For our release, I would say it's too long to see for now. So, yeah. I think we will still focus on those stuff I just mentioned in queue. And the general idea for the Docker team is I think we are still very small. And we don't want to add too much features in Docker. We would like to get a very stable message in queue service. And until we can see some very strong requirements, so personally, I don't want to add too much features in the next couple of releases. Okay. Actually, we need your help. As I mentioned, if you are public cloud, so I would like to ask some adoption for Docker because I can see it's very useful. So the question is, what feature or issues are preventing you from using Docker as a production service? And in this summit, I can see some good things. Now we have a public cloud working group. So maybe we will interlock with them to figure out if there's any potential deplores for Docker. And another question for the developer is, just to be a driver, it's still new. But personally, I really like it. And so I would like to get some feedback contribution for the driver to improve the performance to make it stable. And yeah. So any feedback and contribution about Docker to balance the scalability and latency will be very calm. Yeah. That's it. Thank you. If I understand right, you've got basically a user space or tenant space message queue. Exactly. Is that basically just another instance of rabbit? No. You have a different message transport. I'm just wondering, can you use zero MQ? I would say it's totally different. As I mentioned, technically, as an application developer, you can use Ruby MQ for sure and QPd and zero MQ, any queue service. But you have to maintain the cluster, right? Right. But for Docker, you just use it. You don't have to worry about the end layer stuff. But in the backend and the hood, we are using either Mongo or Redis or Swift as a backend to store your message to get a persistent... Okay. So it's like the Redis R push in L-POP. Yeah. Yeah. So technically, you just use HTTP to post your message and Docker sale your message into Mongo. That's it. Okay. Yeah. It's very simple. And then the other thing was, I'm really interested in the service queue feature. I'm going to review the spec. Yeah. I'd be interested in expanding it beyond Searchlight and Solometer into Nova. And I mean, from my application, I'm interested in hearing all the messages that come in potentially, you know, or subscribing to particular notifications from the different services. Yeah. So I can say I'll review the spec and... Cool. Awesome. Yeah. Thanks. Any other question? No? Thank you. Thank you again for joining.