 I guess we can start. So welcome to the Sendin project update. My name is Drang. I'm the PTL for Sendin. So just a brief background on what is Sendin. Sendin is a clustering service in OpenStack. Sendin allows you to create and manage clusters or groups of homogeneous objects. So the most common use case would be you want to create a group of VMs and you want to manage them. So a bit of background on the project. Sendin was founded in the Metaka release of OpenStack. And in the most recent Rocky release, we had 35 individual contributors. And we had about 159 commits. And over 9,000 lines of code merged. So jumping into the features that were released in Rocky, we had three main features that were added. We had a new detection mode in the health policy. So this new detection mode allows you to create a custom URL and the health engine would pull that URL to query for the health of a node. We also added support for additional NOVA server operations, which I'll explain in more detail. And we added an option to stop a node before it's deleted. So for the node pull URL, we had to make a few changes to the health policy. So we have the detection type. We already had the lifecycle events at the node status polling. And the node status polling is basically actively querying NOVA for the status of the node. And we added a new mode, which is the node status pull URL. And along with that new mode or a new type, we have a few options. We have the interval for the polls. We have the pull URL, which is the URL endpoint that the health engine will query. We have the expected healthy response. So the health engine will match the response from the URL against the string. And then we'll determine if it's healthy or not. We added a retry limit. So you can specify how many times you want to retry before the node is considered unhealthy. We have the retry interval. And finally, we have a node update timeout. And that's an important one to give the node or the VM a grace period to start up before the URL endpoint is ready when it does a recovery. And below we have the recovery options, which haven't changed in the rocket release. So how does this look like in the example? We have the example on the right. And the way you can specify the pull URL is actually you can use a placeholder with the node name in curly braces. And the health engine will go ahead and replace that placeholder with the actual node name during the health check. So that way you can specify the instance name, for instance, that it will query against. The other option or the other feature that we added was the additional NOVA server operations. So as a reminder, if you're not familiar with it, you can execute operations on a node using the node operations API, which is a simple post with the operation name and key value pair. And in the rocket cycle, we added support for the following NOVA operations on NOVA instances. We had the suspend, the resume, the start, stop, block, unlock, pause, unpause, rescue, unrescue, migrate, snapshot, and restore. And the last major feature that was added was the stop node before delete, which came out of a customer request where people wanted to be able to have the node or VM gracefully shut down when a cluster is scaling in or a cluster is deleting a node. So we added something called stop node before delete as a cluster config option. And if that is set to true, then Sandin will call a stop on the node and wait for it to gracefully shut down and then delete the node. And that is specified during the cluster creation, as shown below. In the rocket release, we also had a microversion change. We bumped the microversion to 1.10. And this was done in response to a change in the ADOH project where they changed their payload. So we matched the Rapport Trigger API to the new payload. So the alarm service would be able to trigger the Sandin Rapport correctly. And the details are available in the link. Another thing I wanted to point out, within the last cycle, we had Sandin support added in Go4Cloud. If you're not familiar with Go4Cloud, Go4Cloud is the OpenStack SDK for Go. And it basically allows Go developers to query or make operations against OpenStack APIs. And obviously, Go4Cloud is not part of the official OpenStack project. And the work wasn't done as part of the official Sandin project. But the support that was added, actually, is very important to Sandin because now we have a greater user base of potential co-developers using Sandin. And the support was added in starting in May 2018. And right now, there's about 85% coverage of the Sandin APIs in Go4Cloud. And now let's talk about the features planned for the Stein cycle. So along with the change in Rocky, we had the new detection mode. So in Stein, we really want users to be able to specify multiple detection modes in the health policy. So if you would like to be able to have NOVA, pull NOVA for the status of a node and also have the health engine pull your custom URL endpoint, we will support that by trying each detection mode in order. And we also are looking to add more validation to the asynchronous API calls. So we will be checking for locked resources and for cooldown and progress at ingress of the API. And this will improve the stability of the API. And obviously, we are looking to fix any outstanding bugs. Other things that we're working on is really looking at the stability and the fault tolerance of the health checks to make sure that those can handle errors within when you can't talk to NOVA or the network is down and things like that. And we're also looking to add SPINX extension to auto generate profile and policy documentation based on the source code. So the documentation stays up to date with our changes. All right, so how to get feedback if you're interested or if you have any things that you would like to have addressed, you can always file bugs. You can ask questions in the new combined mailing list open stack discuss. And we also have weekly meetings that are on Fridays at 5.30 UTC in the send and channel. So I welcome anybody can join those meetings. And then we'll also be having an auto scaling forum session tomorrow at 9 AM. So if you're interested, feel free to join that. And if you are interested in contributing, we're always looking for new contributors. So you can help with code reviews. And as a small project, we're always looking for people also who are interested in implementing or helping with the community goals, such as the Python 3 goal or the upgrade checkers. And the documentation, if you're interested in that, you can definitely help with the improvement of that. And we're always looking for more integration tests as well. And here are a few of the reference links. We have our release notes. We have the launchpad where we have the blueprints. And we have our bug reports. And we have the wiki. And that's all I have. Are there any questions? OK. Well, thank you.