 This is Heidi Joy-Truth away with the OpenStack Foundation and the Mataka Design Series. And I'm here with Gord Chung. Gord, tell us about yourself. Sure. So, my name is Gord Chung. I'm currently based in Toronto, Canada. I work for a company called Huawei. So, I've been working at OpenStack since 2012, and I've been contributing as a developer as a developer the entire time. Originally, I was contributing towards the Keystone project, and eventually I changed over to the telemetry project, where I became a corporate contributor, and since delivery cycle, I was given the opportunity to become a PTO of the telemetry project. In addition to the telemetry project, I also contribute to various other projects, also middleware, and something a lot of the slumber developers actually do, given the cross-project scope of the slumber. And lastly, I contribute to ICADF, which is the event audit model that we have in OpenStack and something that we're trying to appropriate through the other projects. Let's talk a little bit about what a slumber should do. So, slumber is actually just one part of the greater telemetry project. So, the function project itself has three components. The slumber, which is the data collection service. There's no key, which is the metric resource indexing storage service, and there's A, which is the alarming service. Slumber itself, it basically just listens to all the data that exists in OpenStack environment, and it normalizes it into discrete data points that anyone can use and extend and kind of leverage to do whatever use case they want with the data. Great. Well, let's talk about the hot topics your team discussed in Tokyo, the Design Summit with last week, and tell us about some of the decisions or outcomes from your discussion. Sure. So, at the summit, we covered a few topics that range across the three services, telemetry, slumber A and milky, and we also worked with a bunch of other projects to kind of help them leverage some of the data that we collect in slumber projects like BitTroj and Kiti. So, one hot topic that we talked about at the summit was regarding the requirement for real-time alarms to solve the NFC use case. Originally, we added this functionality and liberty to have the ability to create alarms based on status changes in the environment. What we plan on doing in the economy cycle is to add better support for more flexible alarm rules and support for horizontal scaling to allow for better scaling of the system. In addition to that, we also talked with the UI. So, as I mentioned before, slumber itself is just a data collection tool. What you do with that data is kind of up to the other services. So, Horizon actually presents an error case using slumber data. But what we found out based on some of the feedback we got was that it wasn't really clear what use case, what use case Horizon was targeting, and it was causing a lot of confusion with users. So, working with Horizon, we decided to kind of simplify the interface, and instead of presenting a bunch of graphs that might be misinterpreted, we decided to kind of focus on crowd operations, like adding the ability to create and delete alarms and simply operations such as that. And we also looked at kind of attempting to integrate Nokia's Grafana interface into Horizon to kind of better handle visualizations and customizations that kind of build different views on the data. And lastly, I think one hot topic that we covered was the performance testing. So, we've actually been doing performance testing, not efficiently, but kind of within our own companies. We're actually doing performance testing on slumber for the last few cycles. But I think in this cycle, we want to formalize that and kind of test out each of the services that the slumber project has, whether it be slumber or Nokia or a kind of dull reference architecture to help operators kind of deploy slumber and fail. And also, we're hoping to find some issues that we can help possibly solve in the coming cycle as well. It sounds like user needs and identifying user needs and problems to solve is a really big part of your conversations. Can you tell us a little bit more about those? Yeah, so we've always been kind of open to the feedback we get from operators. And we actually had a survey prior to the summit just to kind of get their opinion on various aspects of the slumber project. And we got a lot of feedback. One thing we discovered was that the use cases for slumber data were very wide. I think some people are using slumber for monitoring. Others are using it for auto scaling. Some are using it for billing. And at the summit, given the wide scope of what we discovered that users were using slumber for, we realized it wasn't really possible to kind of contain all that functionality between slumber or within the other slumber tree managed projects. So what we decided was that one way we could help operators and users of slumber kind of adopt the service was to provide them the ability to have example configurations. Because slumber itself collects the wealth of data that may or may not be important to different use cases. So if we create different configuration files, we can actually help users kind of minimize the clutter that slumber may end up getting them. And also, we also recognized, based on the feedback that we got, was that we had to better promote the services that the slumber project has, not just slumber, but also A and LB. And also the services that leverage slumber, such as CloudKitty and BitRage, that extend the functionality that slumber collects. So tell us about the new features and enhancements that users and operators can look forward to in the Mitaka release. Sure. So in the upcoming release, we actually, I'll just lift off like one item from each of the services that we provide. So in A, which is the alarming service, we're looking to add multiple worker support for event alarms. Again, that's to handle the NSB use case. In slumber, we're looking to add caching and batch support to help improve light performance, specifically for the NOKI integration. But it should also benefit legacy drivers as well. And lastly for NOKI, what we're hoping to do is adding support for metric archive sharding, which will help improve the scalability of large datasets. So if users want to create datasets that, or capped datasets that are at a per second level for over a year, and the typical slumber in Alpine NOKI, it will involve transferring large amount of data. But with this new feature, it should minimize the data and improve scalability of it. I heard quite a few of the themes that we used to kind of connect the dots between projects mentioned in what you were just saying. The product work group defined five themes, scalability, resiliency, manageability, modularity, and interoperability as key themes we're looking forward to in Mitaka. Can you highlight one or two of those? Yeah, sure. So I think the work band that we kind of captured at the summit covered all the themes, but I think if we were to highlight one or two of them, I think the main one would be scalability, especially revolving around the alarming storage point of view of the slumber. They've practically been, or typically been kind of pain points that users have complained about and something we were hoping to address. And in addition to that, we're going to work on modularity. It was something we started in Liberty, where we kind of broke down the behemoth that was slumber with the smaller, more consumable services. And it's something we're going to focus on doing, or continue doing as well in Mitaka, just to kind of refactor the services a bit more and allow for better integration from external projects. Is there anything else you'd like to add for the folks watching? Sure. So I guess from a contribution point of view, the slumber-based and no key projects are always willing to have more help from contributions, new contributors, whether it's new features or bug fixes. I think in addition to that, being heavy contributors to the AUSL projects, we're always looking for more help in AUSL as well, especially around AUSL messaging. The message queue is actually a very important role in the entire AUSL framework. And I think sometimes it's a little bit neglected, so if people want to help out there, it would be great. Great. Thank you for taking time to talk to us today. We appreciate it. No problem. Thanks very much.