Welcome to yet another session of our NPTEL on nonlinear and adaptive control. I am Shrikan Sukumar from Systems and Control IIT Bombay. So we are into the sixth week of our course. So we are sort of at the, almost at the halfway monk. And we have already covered quite a few different tools for analyzing on linear systems. And also adaptive systems and also parameter identification laws and their convergence. Thank you. So starting this week, we are going to look at how to actually design adaptive controllers. So this is sort of the plan. And of course, as always, we have this very nice motivational background of this SpaceX satellite orbiting the earth. And the hope is that the algorithms that we design and develop will help drive systems such as these autonomously. So what we were, we had sort of started looking at last time was an introduction into the first adaptive control problem for this course. All right. So, so thank you for your patience. And of course, you would have probably hoped to see an adaptive controller, which is the topic of the course, which is the name of the course. Sooner maybe, but well, I mean, we of course had to cover quite a bit of preliminary material in order for us to be able to understand and design adaptive controllers. So great. So we had just started with our scalar first order system. So I'm in fact going to mark this piece as lecture 6.1, just for a reference. So we had looked at sort of an introduction of what we want to typically do in adaptive control. We looked at this first order scalar system, where we have a constant unknown parameter appearing linearly in this system.  All right. And this and this theta star constant, which is unknown appears linearly in this system. And we have the control objective of the state X of T, tracking a smooth bounded trajectory. And we also stated the standard assumptions that are prevalent in all adaptive control designs. Yeah, at least most adaptive control designs and definitely the ones that we are going to focus on in this course. All right. So this is where we are. And this is where we will start a lecture 6.2. This is the second lecture of this week. Yeah. So the first thing that we do is design an error system. So, so why do we do that? Why do we design an error system? We are almost always interested in driving things to zero. If you remember when we were sort of talking about stability of nonlinear systems in the sense of Lyapunov, we eventually started assuming at all points that, you know, the equilibrium is the zero or the origin is the equilibrium. And that's why we, whenever we are given a tracking problem, for example, where a signal X has to track a signal R, we simply construct an error signal, which is X minus R, so that whenever this E goes to zero, we know that X goes to R. Right. So this is essentially the aim of constructing an error signal. And once we have an error state, if you may, we write the error dynamics just by taking a derivative, of course, and substitute for X dot from our original system dynamics, we get something of this form that is an equation 2.8. All right. So here, the first two pieces are essentially the same as what you have in the system dynamics. And you just have a minus R dot corresponding to the reference trajectory that we are trying to follow. So it should be sort of obvious to you that if you want, if your reference is a constant, that is, if you want to move to a constant value or to zero value, then R dot is zero. And therefore, this piece is also similar. All right. So whenever you're trying to track a constant reference, then it's typically, this is called the, if R of T is constant, it's called the regulation problem. Yeah. The tracking problem is when R is a function of time. The regulation problem is when R is a constant. And if R is zero, if R equal to zero, it's called the stabilization problem. So three kinds of problems. One is if R is a function of time, just like we have written here, then it's a tracking problem. If R is a constant value, then R dot is zero, and it's called the regulation problem. And if R of T is in fact zero, that is, you just want to go to the origin, just want the stage to go to the origin. Then it is called the stabilization problem. All right. So there's just nomenclature for you. So anyway, so this is what are the error dynamics. So this is the error dynamics. This is the system that we will work with. This is the system that we will work with. So the first step in any adaptive control design is to design a controller, assuming that the parameter is known. Of course, this is called the known parameter control design. Okay, so this is the first step. Again, sort of, this is the very standard sort of thing that mathematicians and applied mathematicians do. We've already talked about this. You try to solve the simpler problem first so that you get some nice ideas to solve the more complicated problem. All right. So that's really what we're trying to do. The simpler problem is when this parameter T does that is just assumed to be known. And the question is, can you construct a controller U so that E is asymptotically stabilized? All right. So how would you design this feedback? So one of the simplest ways to do this is to imagine or to sort of specify a target system. All right. So then the standard question that arises is what is a good target system? So it should be obvious that any target system should be set that the, in that it is for the target system, the error is converging to 0 as state of infinity. And also it's asymptotically stable. And so your target system should be nice. It should do what you wanted to do. In our case, you want the variable E to be asymptotically stabilized to 0. And so therefore you should have a target system which is asymptotically stabilizing to 0. And second, you should ensure that the target system has some similarity to the original system. Right. For example, if this is a first order system, just like it is, it would be sort of ridiculous to consider a second order target system. Because I will never be able to compare this and this. So things like that. So the target system should sort of match the original system. And it should have nice properties of asymptotic stability that you desire from the original error system. Okay. So in this case, what do we choose? We choose a target system. Maybe E dot is minus K E. Why? We know the solution for this. It's a scalar system. So I know that this is in fact exponentially stable. Right. So it's a good, it has good behavior of E of K. Okay. The second thing is it should be close. It should match. What do I mean by matching? I mean that by choosing some control here, I should be able to match this right hand side with this right hand side. And yes, it is in fact possible by choosing a control of this kind. All right. So this is an important thing to remember. So I'm going to repeat it. The target system is chosen to be E dot is minus K E. The first sort of principle of choosing a target system is that it should behave well, which in this case means E is asymptotically stabilized for the target system, which it does. In fact, exponentially stable. The second is it should sort of match the original system. What is this match? It means that by choosing an appropriate controller, I should be able to match this right hand side with the target system right inside. Okay. Yeah, this is these two are important. And in this case, indeed, I can do that just by choosing U to be of this form. So the second term here cancels the term corresponding to the trajectory. The last term cancels the dynamics. Notice that we have assumed theta star is known. Otherwise, this control is not implementable. All right. So if theta star was unknown, I cannot implement this control. Yeah. So this is not an adaptive controller. It was just a controller in the case of the known parameter. Yeah. So this just cancels the nonlinear dynamics. So this cancels the trajectory component. And the first term helps with the matching. The first term is essentially what helps with the matching. So now that we have this, we know that this is exponentially stable. And we also can very, very easily construct the Lyapunov function, which is just the basic one half E squared. That's the simplest possible choice. Which is, in fact, radially unbounded in all the nice jazz, which you look for in a Lyapunov candidate. Yeah. And further, if you take V dot, so this is the closed loop system. Now, if you take V dot along this closed loop system, I get minus scales. And therefore V dot is also negative. So in fact, you get global asymptotic stability. Yeah. In fact, you get global exponential stability. Why do I get global exponential stability? Because V is just half E squared. So it is bounded on both sides by this class K infinity function, which is half E squared itself. You can take half E squared itself. And further V dot is also, you know, V dot minus V dot is also upper bounded by a class K infinity function of the same magnitude. They can use just K squared here. Because it's the same order of magnitude class K infinity function. Therefore, this is in fact globally exponentially stable equilibrium. So E equal to zero is globally exponentially stable. So this is in fact more than what we're looking for. But well, in this case, we are able to do that. Okay. So what have we been able to do? We've been able to design this controller, right? For this known case. Yeah. For this known case, we have been able to design this controller. Yeah. With this, of course, K has to be a positive constant. Yeah. And that your error exponentially decays to zero and is asymptotically, in fact, exponentially stable equilibrium. And zero is an exponentially stable equilibrium of the error system. So essentially everything that we want. Yeah.  Of course, I mean, it was not very hard work to be able to construct a stabilizing controller. Right. As you would have imagined. Yeah. So for the known case, we are able to do all the book things. Excellent. And as we should, we are very happy about it, but not a big deal. Still a scalar system. Right. Great. Now, the next step now is to design the controller for the unknown parameter case. That is when theta star is unknown, what do we do? How do we construct an adaptive controller? And this follows a very, very simple logic and this logic is stated in the form of the certainty equivalence principle. So the certainty equivalence principle says that in order to design the controller for the unknown case, we retain the same controller structure as in the known case and replace the actual values of the parameters by the estimates. Okay. So the certainty equivalence principle, so certainty means that when the parameter values are known equivalence means that the structure of the controller remains exactly the same. The only thing you change is replace the true value like this, that is the theta star by its estimate, which is denoted by theta hat. Okay. This is very important. So we always use the theta hat to denote estimate of theta star. So the hat operator denotes the estimated value and the tilde is the theta minus theta hat or theta star minus theta hat is the parameter element. This is very standard notation that we will continue to use throughout this course. And so please get used to this notation. Theta hat or the hat notation always indicates an estimate. The tilde notation always indicates the parameter element or the estimation error. Okay. So what do we do? We pick up the same control law as 210 and we replace this theta star by its estimate theta hat because everything else remains the same. Notice that we are yet to prescribe how theta hat is calculated. Okay. So this will come subsequently. But for now, all we do is we replace the true value theta star by its estimate theta hat and this is what the certainty equivalence principle dictates. Yeah. So now the important thing to note is that because theta hat may not be equal to theta star as would be natural because you don't know the value of theta star. So you cannot possibly have an estimate which exactly matches the theta star. Right. So when you write the error dynamics, there's a small change. The first term and remains the same. But then there's an additional term which arises because of the parameter error because this theta hat is not equal to theta star and error term shows up here. And this is the theta tilde that we are talking about. Okay. So one of the things that should have already come to your notice is that I have very carefully put in a time argument on the estimate. Okay. Although my original parameter was a constant, my estimate of the parameter is an evolving object. All right. It is always evolving or changing. Yeah. Over time. Therefore, it is a function of time. It is not a constant. Yeah. Because there is literally no logic to having a constant estimate for another constant because if your estimate is wrong, you never get to sort of improve it. Because you chose a constant estimate. Yeah. So if you chose an estimate which was off by, you know, 10 units, then it remains off by 10 units all the time. You can never improve the performance. You cannot expect to cancel the effect of the unknown parameter if you did not choose a time-vary estimate. Okay. So there is no point in having a constant estimate for another constant. So although our true value is assumed to be a constant to the entirety of this course, the estimate will always be a time-dependent quantity. All right. Great. So now we have a different closed-loop system, which is this guy. Yeah. Which contains the parameter error node. Right. So, so what do we do? We now do what is called Lyapunov redesign. Yeah. And what is this? Which basically we use a Lyapunov candidate in order to come up with an update law. This is a very standard method. Right. So what is the idea? Idea is use Lyapunov candidate to derive theta hat dot update law. Yeah. So the expression for theta hat dot, that is the expression for evolution of the update is called the update law. It's the natural name. So what's the idea? I first guess a Lyapunov function. I don't guess a theta hat dot. I don't start by guessing a theta hat dot. I start by guessing a Lyapunov candidate. Okay. And what's the simplest Lyapunov candidate? I pick the original candidate, which was half east point. For the known case, if you know, if you remember, it was half east point. So I choose the original piece, but then I know that there is now another state. Why is there another state? I introduce the parameter error, which appears in the dynamics as a state. Okay. And therefore I add a term corresponding to that state. Okay. This is something like one over two. Right. One over two gamma theta tilde square where gamma is just some positive constant. Okay. Where gamma is some positive state. All right. Excellent. Excellent. So it's a very, very simple choice. Standard, simple quadratic choice. Yeah. Nothing too complicated. I chose whatever was already there. It's just one half east point. Added to it a quadratic term in the new state, which is the parameter error. Yeah. And that's with some positive gamma. So now for this system with theta tilde and E as our states, this is in fact, positive definite. Yeah. So, so in fact, V is radially unbounded, not just positive and definite. Right. It's just quadratic sum of two quadratics in the two states. Okay. So what do we do? Well, I mean, of course, gamma is what is called the adaptation again. It will show up soon in the update law and you will understand why it is called the adaptation again. So what do we do? We take the derivative of V. We take the derivative of V and we substitute from the error dynamics here. Okay. So what is the derivative? It is simply E E dot minus gamma theta tilde theta hand on. Okay. So the question is, why did we get a minus sign? This is because of how we define theta tilde. So theta tilde is equal to theta minus theta cap. And so theta tilde dot is equal to minus theta hand on those theta star is a constant. And this derivative is, of course, zero. So this is how you get the negative. Okay. So all that we have done is taken the derivative of this week. And now for E dot, we substitute the dynamics. So we do nothing for theta hand on because we have not even specified the dynamics for theta hand on. So we do not do anything, but we plug in for E dot from the dynamics. And once we do that, yeah, and you just expand it out, you will get the first term minus K E squared. Notice there's a nice negative term already. So we like this term. We're not going to mess with this term because K is positive. And so this is a minus K square, nice negative. All right. And then you get the term corresponding to the parameter error. So this term would not have existed if the parameter was known. So this is there only because there is a parameter estimation error. And that is simply theta tilde F times E. Okay. So the first two terms are just coming from here. And the last term is copied as it is. Last term is copied as it is. Now, behold this magic. Yeah. What is this magic? Both these terms have theta tilde in it. And both these terms have theta tilde in it. And so what do I do? I take the theta tilde common. Right. See, if there was no theta tilde in one of these terms, for example, there was no theta tilde here. It would have been a difficult challenge to specify theta hat dot because this theta tilde is multiplying theta hat dot. So in order to specify a theta hat dot, I would have had to have theta tilde in the recipe profile. And this creates all sorts of problems. First, theta tilde is not known. Theta hat is known, but theta tilde is not known. Therefore, having theta tilde in any kind of update law doesn't make any sense. It's no longer feasible. Yeah. And secondly, you never want to design any controller or update law with states in order. Yeah. Because if they go close enough to zero, then things will blow up for sure. Yeah. So you don't usually have ever design update laws or control laws with denominators containing the states. Yeah. So this is something that you should be very careful about. Okay. So this is a rather nice coincidence, if you may, although this is just an outcome structure of the candidate app on a function that both these terms are theta tilde, which can be nicely taken out. And then what we are left with is these things. Now notice gamma is strictly positive. So can be divided now. Yeah. So not a big deal. So what do we do? We do the best thing we can. Yeah. Because this is a mixed term. I don't even know what this is. I cannot have a theta tilde in theta. Because like I said, theta tilde is not implemented. Theta tilde is not known. Yeah. So this is very important. Theta tilde is unknown. Many, many students make these mistakes. Theta tilde cannot appear in the control or update. Law. Because it's important. Yeah. If you ever designed an adaptive control and your theta tilde or the parameter error appears in the update law or the control law, then you did it wrong. Yeah. Because you cannot have an unknown. Yeah. Because it doesn't implement. It's as simple as that. Right. So what do we do? So we do the best thing we can. We simply cancel this one because it's a non-definite, indefinite quantity. We don't know what to do with it. We simply make it, try to make it zero. And that's what we do by choosing this end of the theta hat dot. All right. And once we make this choice, this term goes away. And we are left with just this. Okay. Now look at this carefully. I say that this is negative semi-definite. All right. Why do I do that? For the known case, if you notice, I had the same expression for V dot, although the V was different. I had the same expression for V dot. And I said it was negative definite. But here I say it is negative semi-definite only. Why? Simple because the system now has two states, not just like in the known case, but also theta tilde, that is a parameter error. And I have said this quite a few times that any Lyapunov candidate or its derivative, if it does not contain all the states, it cannot be definite. Okay. For a function to be definite, it has to contain all the states. There are no two ways about it. Now, V dot does not contain all the states, but it is definitely non-positive. Therefore, it is negative semi-definite only. Right? It's only negative semi-definite. So what do we know? We can, as always, apply the Lyapunov theorems. And what will I get? Yeah. I will get that the system that is the errors dynamics or the E theta tilde dynamics is uniformly stable at 00 equilibrium. Whenever I talk of stability, it is important to specify the equilibrium. Right? So we only get uniform stability from the Lyapunov theorems. Yeah. We cannot get anything more. Why uniform? Because, of course, your V and V dot do not depend on time explicitly. And therefore, you have uniform stability. Okay. So, which is nice, which is a nice property, which means the straight trajectories are going to behave well. Yeah. Not start to blow up and stuff like that. However, we cannot guarantee that they converge to the origin. Right? Syntotic stability has two pieces, right? It is stability and convergence. Right? We got the stability. We don't have the convergence. All right? So in order to go analyze the convergence, we need additional tools. And what is this additional tool? This is, of course, the Barbalance learning. And what is called signal-chasing units. Yeah. And this is what we will sort of start with next time. Right? So, great. So, what did we look at today is that we started to discuss an adaptive control design for a first order scalar system. We first designed the controller for the known case. And then using the certainty equivalence principle, we obtained a controller for the unknown parameter case. In order to derive an update law, we guessed a Lyapunov function first or a candidate Lyapunov function first and then took the derivative in order to guess an update law. And until today, we have been able to prove that the system is uniformly stable using the Lyapunov theorems. But we, of course, want to move in sort of claim mode. Yeah. Which is what we are going to look at in the next section. All right. So, this is where we start today. Thank you for tuning in.


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 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.  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.