 as I talk, but go ahead and get started. My name is Gabriel Hurley, I am the PTL for Horizon. I've been working on Horizon for the past couple releases and put a lot of work into it. Happy to be here. A little bit about me, I currently work for Nebula Inc. I previously came from NASA Ames, so I worked under Chris Kemp there, not directly with the same team that originated NOVA, but shortly thereafter. Before that, I was an open source web developer, I'm a core committer for the Django project. It's a Python web framework for those of you who don't know. I have sort of a strong background in open source in general. So, as most of you know, here to talk about Horizon give you a little retrospective of where we came from and where we're going. So, first off, Horizon. I think you're probably gonna all be familiar with this, but it's the OpenStack dashboard project. It was first included as a core project during the Essex release. So that means that this is our second release and it has about 50 contributors from a whole bunch of different companies. While a few people, as with most of the projects, do a lot of the work, we actually do have a very diverse space. And one thing that is not immediately obvious is that Horizon ends up being the consumer of every API in the OpenStack ecosystem. So we feel all of the pain. If you hear me yelling in API sessions, this is why. Looking back to where we started and to Essex, I like to take the view of principles. I really like this quote, the think simple as my old master used to say, meaning reduce the whole of its parts into simplest terms, getting back to first principles. And the first principles that I laid out for Horizon back in the Essex timeframe were core support that Horizon should have built in out-of-the-box support for every core project in OpenStack. It should be extensible so that not only core projects can be in Horizon, anybody else can add their project and build on it. It should be easily manageable for developers. The core code base should be simple, easy to navigate, all makes sense, nothing's tucked away or weird structures that you're not gonna be able to figure out. Should be very consistent in terms of the presentation to the end user. All the visual design should be very familiar. Shouldn't be any jarring changes from project to project. Your Nova panels shouldn't look different from your Swift panels, et cetera, et cetera. And that's actually a big problem that we had in the very early days because it was all kind of copy-paste from one piece to another and little changes would creep in and things would be slightly different from place to place. And it should be stable. Basically, from my previous background in OpenSource, I really believe in backwards compatible APIs and in version to version stability. Lastly, needs to be usable. If it's not usable, we're just failing it being a dashboard. So, we wanna make an awesome interface that everyone actually enjoys using, not just sort of slogs through because it's there. So, how did we do? Where are we now? Core support. I think we're doing really well on that one. We've got full support for Nova, Swift, Glance, Keystone, and Cinder. And as of the Folsom release, we have support for Quantum as well. The Quantum support is a very new thing as is the project itself. But we got that in there, do some great work by Akihiro Motoki. I hope I said that more or less correctly. And we're gonna continue making it better. There's a lot more work to be done. There's a session on Thursday to plan out how we're gonna integrate some of the things like load balancers of service as that comes in, do the various L3 networking. Really make that an awesome experience. Hopefully get some great interaction in there too. Point number two, principle number two, extensible. Basically, we took what the project originated as, which was just this huge copy and paste from piece to piece to piece. It was thousands of lines of boiler plate that needed to be reduced. And we've taken that and turned it into a really elegant framework that basically anybody can come in, take the pieces off the shelf, put them together, build their own dashboards from them. And not just open stack dashboards. You can actually build a dashboard for anything with an API from it. I myself have built dashboards with it to interact with Amazon services and internal Nebula APIs. I was shown earlier a dashboard that works with Nagios monitoring. There's cool stuff you can do with it. It really is reusable and extensible. So I also wanna highlight that the quantum support that I mentioned was added entirely by the quantum team. I gave them some guidance, but they were able to come in, put it together, figure it out. They made the whole thing happen. So I consider that a win on the extensibility as well. That with our documentation and the examples, they got the whole thing working on their own. And moreover, heat and salometer, the two projects that are kind of up and coming that everybody's excited about right now are both looking at horizon integration and have even started on it and largely aren't have any problems with it. So we're meeting our goals there. And as far as manageability goes, as of the first two commits in Grizzly, I am actually extremely pleased with this. I think there's a really clean separation between the horizon framework code and the actual open stack dashboards. One of my goals here is to actually create, is to take horizon to being that completely generic framework for building dashboards. Like I said, you should be able to build dashboards for anything, not just open stack with it. And part of the importance of this clean separation is making sure that somebody who wants to build a dashboard for something that's not just a direct open stack core project, doesn't have to import all this open stack code just to make it run. The two still live together and the open stack dashboard is the whole point of this project for the open stack community. It will always be a first class citizen there. But in terms of maintaining that code and making it navigable, keeping them in a logical structure is really important. So as I said, cleaned it up in Grizzly. Stability, I think horizon might be the only project that can actually say that it is fully version to version compatible. Essex to Folsom, 100% compatible. Everything should work. There are a few features which are triggered by the Keystone service catalog like quantum support, which quantum didn't exist in Essex. So if you turned it on somehow, you are gonna get some weird results because you don't actually have quantum. But otherwise, if you actually had a properly working Essex stack and you put a Folsom dashboard on top of it, you're good to go. Very proud of that for the whole team. We all were very diligent on that one. The API for developers also remained fairly stable. There were a few backwards incompatible changes. Some methods got renamed, things like that. Those were all noted in the release notes. So I think we did pretty well there as well. We kept the settings changes for deployers minimal. I think that's the area where we need to be most vigilant going forward. I've seen a lot of talk on the mailing lists of people referencing settings that haven't existed in several versions. And that's a problem with blog posts and lots of people writing documentation and lots of different places. Things creep in and when we rename them or remove them, they end up not working anymore. People get confused. So I think we can do better there, but we're doing all right. And lastly, usable. In Folsom, we added what we're calling workflows. So basically these are more complex interactions that may span multiple services or do some multi-step task that would normally you'd have to go to your one place in the second than third. Kind of a pain in the ass for users. Launching instances and attaching volumes and assigning floating IPs are a great example of this. Now you can kind of do all these things in one place. One step, one button. If you notice that I'm not demoing a lot of these things, it's because all you have to do is walk out into the main hall and you'll see these everywhere. Every booth has horizon up on the screen. And I think that's a phenomenal win for the project. I think that really, that shows more than anything that we're doing the right thing. People are using this. People are showing it off. People are taking advantage of it. So that's my apology for no demos. If you wanna see it, I can show you anytime. But on the usability, we can do better. People definitely call out horizon as being fairly generic, being fairly kind of plain, boring, very resource-oriented view of the system. And I think that's where the usability needs to step up. That's the next stage for horizon's development. So we've gone through the principles. What does it all mean? Horizon Res, it is, presents just the capabilities of the OpenStack platform. And that's useful, but it's very limited. That doesn't really give you anything interesting. That doesn't grab attention. And the other point is that OpenStack, as a whole, is still very infrastructure as a service-oriented. We're not quite to the point of getting to that platform layer or that software layer. And that's where everybody wants to be. I mean, nobody's kidding themselves about that. That's where the fun happens, especially in a dashboard layer. But we're not there yet. And so horizon reflects that fact. We still have to be very resource-oriented. You still have to upload your images and manage those. You still have to launch your VMs one at a time. Seeing things like heat come out and salameter come out, those are gonna do a lot for us in terms of being able to add meaning to the user's experience. And especially in terms of things like salameter and other projects like that, really differentiating the experience for different types of users. And admin could go in and much better understand what's happening in their system. I will certainly be the first to admit that right now the end-user project dashboard and the admin dashboard pretty much clones of each other. The admin dashboard, you just see everything. We can do much better there, and we will. That's one of the focuses for Grizzly, which I'll talk about later. What we're also doing is we're providing that platform for all of the ecosystem projects. Back at the Essex Summit, which was in Boston, that was my first summit, I heard a lot of people going, we want to be able to get into Horizon. How do we get our project into Horizon? What can you do to get us into Horizon? And Horizon was looking like a bottleneck. There's no way we could get all these projects integrated. And I think we've answered that question in spades. I talked about it earlier, as far as extensibility goes. Projects are building their own dashboards, their own panels. People in the community are building all sorts of interesting little drop-ins that you can use. So that's definitely gone really well. People are working on the integration. As I said, we're not the bottleneck anymore. And more importantly, we're not the decider on what gets to be included. I mean, I laid out that core projects should be supported out of the box, but it would be a disaster if that was all you could ever get into it. There had to be an extension mechanism. And at this point, you can download any piece of code that's written for Horizon that you like, get it off PyPy, get it off GitHub, wherever, put it in your list of installed apps, and you're good to go. And as I said, we try to offer guidance to other projects and developers. Anybody who wants to build something, happy to talk to them directly, email the mailing list, and we'll help you build. And more importantly, if there is some interaction that you need, those are what we wanna build. That's what the core Horizon team should be working on. Because if we build it once and build it well, then everyone gets to take advantage of it. Everyone wins. And there are some pieces like that that I'll talk about later too that I wanna see coming down the pipeline. So in the near future, that's Grizzly. So the first thing I wanna do is I wanna make sure that all the crud, the create, retrieve, update, delete, trivial, you shouldn't have to write any code for that. There's no reason. Even looking at the code right now, 90% of that code in the actual OpenStack dashboard is just templating for that crud. Laying out those views, laying out those API routes, laying out those templates, it could all be auto-generated. So there's no reason with a reasonable definition of what this API resource looks like that you'd have to write any code for it. So I wanna make all of that as dry as possible. Developers should be focused on the bigger picture, the complex interactions. What can you really do with this? What makes this unique? And I think if we get all of that out of the way, it will much better encourage that type of behavior. That is a perfect segue into those user-focused workflows. And part of that is also about differentiating the workflows that an end user needs versus a project administrator needs, versus a system administrator needs, versus say an executive needs or someone like that. And there is a whole section on what I think those should look like. But that's where we're going in Grizzly. I really wanna see file uploading work. This is not a simple problem, both from an interaction standpoint of providing progress indicators, things of that sort. Or from a backend side of what do you do with these files in the intermediate transfer when they're actually going out somewhere else to glance or to swift. There are some solutions in some projects, but we need to get that consistent. We need to make that work because it's a really important piece of the puzzle right now. For an end user, it's very frustrating to not be able to upload an image to glance without having to type this truly arcane command line set of arguments and confuse it the heck out of me even. And I know what I'm doing with it. So that's gotta work. And the quantum support, as I mentioned, there's a lot more coming in quantum in Grizzly and there's a lot more in quantum already that we don't have. And we're gonna make that awesome. That's a really critical piece of the puzzle as far as open stack goes. So that needs to be really well represented in the dashboard. The not so near future, future plus plus. We're basically, we're starting to get to that inflection point on the curve where new projects are actually coming along much more quickly than they used to. We've seen a lot of new things coming out being announced just this summit or in the last few weeks. Cylometer, heat, synapse, the Comcast guys with their CQS and CNS is people announcing things left and right. So as those keep coming down the pipeline, some of them may be core, some of them may not, but we wanna make sure that they're all useful and well integrated in the dashboard, that those workflows that can span multiple services should encompass these in ways that if they are enabled, if these services do exist in your deployment, that you can do really cool stuff with them. Making that easy and flexible and seamless to the end user as simple for the admin as possible, that's the goal. I talked a little bit about the platform as a service and software as a service earlier. As I said, we're not there. We've got a lot of competing solutions right now, all the cloud foundry stuff, the heat project, open shift, everybody is trying to get there. There's, I mean, by the end of Grizzly we'll probably have a dozen different projects that are all doing pieces of the puzzle. And as such, there's no standardization. Nobody's picked one, nobody, no project is one and that makes it nearly impossible for Horizon to support one. Horizon can't lead the charge in that arena. As much as we would like to, because we're so user-driven and users want this, we have to be patient. It's unfortunate but true. But just because there's no standardization doesn't mean that there can't be a common interface to them and if we can achieve that common interface as a community, then Horizon can start building on it. Then we can start taking advantage without having picked one winner or without excluding everyone else. And we will support it as soon as the community is there, as soon as there is that interface, as soon as we're not shooting ourselves in the foot by picking one or blessing the wrong project, that's what we wanna do. That is obviously the future. We're all gonna get there and it's gonna be great. I'm so excited for it to happen but not there yet. And the other piece is that I wanna make it as useful for the various people who use it as possible. As I said earlier, it's pretty generic between project and admin right now. There's no real differentiation. And I think basic users, like just an end user, a green field researcher out in their lab, basic like admin, well, I was gonna say admin but that's the wrong, such overloaded terms. The basic accountant or something sitting at their desk, they don't need all these, they have no interest in how do I upload an image and then how do I connect my floating IP to it and all that and no, that's silly. Simple workflows, obvious. A lot of the other dashboards out there, they have a nice little guided, here's your new, let me show you around. Let's make this simple, walk you through, click by click on what is this, select your, which image you want, go ahead and launch it. Take care of it for the end user. There's no reason for it to be so complicated like it is right now. But a lot of people want that complexity. It's trying, we've been trying to find that balance but in the long term we have to actually allow people to set the degree of complexity that they experience to their own needs. And that is gonna be someone like a project administrator who actually as opposed to launching a lot of instances and doing the individual nitty gritty of the work is more interested in supporting the users in their project. They need some limited subset of admin capabilities. They need to be able to know what's going on in their project. They might want to pre-configure some images for their project, things of that sort. And I will add on a tangent here that this is one of the pieces that I feel is completely misconstrued in OpenStack right now is this idea of these types of roles and particularly admin versus member in all of the projects right now because we have this paradigm where if you are an admin anywhere, you are an admin everywhere. There is no yours, mine and ours in OpenStack. There is the projects or there is public, that's it. And that really, really screws with this whole mentality. There's no way to actually do things just for the subset of users that you are responsible for. And we really need to get that differentiation into Keystone and into the stack as a whole. Hopefully some of the policy and RBAC stuff will improve that, yes, thanks Joe. I see you there. Oh yeah, no, I expect it, thank you. Hopefully we'll get some of that with the policy pieces but I think there is still a fundamental problem of there not being a differentiation between what is mine as a user, what is my projects as a shared pool and what is globally accessible. And RBAC alone doesn't solve that problem so it's a larger issue to be tackled in the long term. So up that next level you have the cloud administrators who are, they really don't care about your images, they don't really don't care about any given VM that you're running. This is the cloud scale view where a list of all the thousand instances running in your cloud is useless. That's just that it's a big table that you can't find anything in. They want to see overall system utilization, they want to see problems, they want to see spikes. We really have to re-envision what that kind of management and what that kind of interaction looks like. I think it probably involves a lot more visualizations and things of that sort. But that's a possible view there. And then there's the role of executives or anybody else who's not technical but they want to know what's going on in their cloud. They need a simple, understandable, at-a-glance interface, probably really robust reporting, tools like Solometer to see what's happening in the cloud but they don't need to be going in launching instances or something like that. If they're greeted with a workflow that says, hey, here's how you launch an instance. That's really, that's not serving them at all. That's silly. I want to provide a lot more just kind of at your fingertips useful capabilities. Things like making the VNC console or on Windows images like a RDP remote desktop right there, easy, make it really work because it's been a very frustrating experience in a lot of deployments that it's flaky or sometimes it doesn't work or you can't get it set up, things like that. If this really just was a simple go in, do what you need to do, that would be great. Like I said, for admins, much better visualizations. I think there's a lot of information that can be surfaced out of this and integrating existing tools that people already like to use is the way to go. Like I said, I have seen integrations with Nagios, I've seen integrations with other monitoring tools. I myself have written visualizations for doing flocking. Jesse Andrews had a really cool visualization where he was doing kind of a node graph to show both project and node health along with an overall view of the system. There's really cool stuff you can do there. And if there's anything that I would love to see the community get excited about, it's contributing those kinds of things. If there is a cool way to visualize the data, that adds so much value to the dashboard. So if I can ask for any one thing, that would be it truly. I really wanna see us get to a real-time event-driven system. Right now there's a lot of polling going on both in the dashboard and in OpenStack as a whole. I know there are talks on the message bus system that's in common right now. I think that one's actually session after this. There are talks about the notification system that Comcast just released. There are a lot of ways we could go here, but we need to get to the point that everything is being pushed up to the client, the client being the browser in real-time and only when things are actually happening. A dashboard in which you actually could see progress and status of everything, the moment it happens, someone else in your project spawns up an instance and you see that instance appear in the overview and you see that quota change, you see that utilization change. That's a much more powerful and much more meaningful experience to an end user. That is one that Horizon can't tackle alone too. It's one that we really have to work with the entire stack on because everybody needs to be using a common notification system for that to work. I was talking to Nick Marcette about the Solometer work last night and how they've had to come up with these three different mechanisms for gathering all this information. That is the challenge and we all need to work together to get there. If we can bring this into one setup, that'd be great. And he's worked closely with the Cinder team and the Quantum team to get them to use the message bus and it's starting, it's starting, but put it in your head and when you go out and talk to people from other projects, put it in their heads. It's the only way we're gonna get there. And as I talked about earlier, all these new projects coming along, the more we can support them, the more we can bring them in, the more we can integrate them in ways that don't require them and don't break if they're not there but provide really rich interactions if they are there, that is the future. So what's challenging right now? What I was just talking about, the cross project aspects, being able to do things that don't exactly fit into any one project. One of the real challenges that we have as a management perspective right now is that there are no cross project blueprints. Launchpad doesn't really do that too well, has to live in a given project and you can sort of connect them and target them and things like that but it's very frustrating. So one of the things that I, every summit come here and talk about is getting this consistent set of API features. We need to really nail down things like how do you do pagination? How do you retrieve a whole bulk list of objects? How do you do X, Y, and Z? And I have a talk on that on Thursday. I think I don't remember what time off the top of my head but that's definitely one that, what I wanna see is a sort of a manifest, a design document that just says this is what an API should look like. It doesn't specify the structure of the routes or what data exactly is returned in what form but it says an API should support these capabilities. It should support pagination with these queries. It should support filtering based on the parameters of the resources that you're retrieving. Basic capabilities like that. If we had a common understanding of what they should look like then we could all start working towards getting to that point. It's not about rewriting everything from scratch. No, it's an eventual goal and I just talked about the notification system. That is crucial. Design, that's the other tricky one. That is the bane of most open source projects. The usually the only way that this truly works out for an open source project to have great design is when somebody comes in and sort of becomes the benevolent designer for life, another form of BDFL. Cause someone really needs to own it. Someone needs to have vision for the look, the feel, the texture and that's lacking now. As I said, Horizon is a generic solution right now and I've seen a lot of custom dashboards which have sexy interfaces and stuff like that. I would like to get there. And on that note, I've said this in other talks into individuals. I fully support other projects, other companies having their own dashboards. Horizon is not meant to be the only dashboard. Horizon is meant to be the dashboard that meets the needs of the community. And the community is very large and very diverse and has a lot of different needs. So we have to be the middle ground. We don't get to be the cool dashboard that's really customized for the biotech market or something cause we could be a great biotech dashboard but that leaves everybody else out and that's not what we're doing here. So I just wanted to make that known. I don't have any objections to other people's dashboards. In fact, I love seeing them cause they're inspiring. It's really cool to see like, oh man, that was a great way to do that. It's a great solution to that problem and sometimes those people can contribute those ideas back. They can contribute to the human interaction guideline document that we created in the Essex timeframe to say, you know, that was a good idea at the time but trends in the web have changed. There are better technologies for that now. We can do better. So there's a place for everyone in that community and I know some people have concerns that other dashboards fragment the community or do things like that. I really don't see it that way. So I find great value in them. But back to the idea of design. We've got great contributors adding a lot of really awesome features right now but I do think that it is time to make Horizon sexy. I think we can really make it something that people are excited to use that when they first log in, they get a great experience and that really will help spread OpenStack as a whole. If we can start demoing to our customers, to our users, et cetera, something that really looks good that triggers that like primal, you see it and you want it. You're like, oh, that's cool, I want that. And I think that would be a great thing for the project. It fits really well with Horizon. What I see is Horizon's mission as a whole which is that Horizon is kind of the face. It is the first touch point that most users have with OpenStack. And so we have to provide a good experience for those, for that first touch point. We need to impress people. We need to just work. We need to make it simple. We need to get done what they want to do. I think that's pretty much what I've got. So I want to say thank you to all of the developers. I want to say thank you to all of you who came. And we've got plenty more good work to do. And I'm happy to take questions if people have things they would like to know, ask, hear about. Yes, Nebula actually does employ a interaction designer who has done a lot of design research with actual customers using the OpenStack dashboard. He has done, he created the human interaction guideline document. He regularly contributes to the overall direction of what gets built. He's certainly some of the interactive elements like the kind of browser interface that we introduced for Swift were creations of his mind. I myself have some amount of design background. I've taken some formal design classes and I worked for many years in graphic design. So I have some background there as well. But we need more. We can definitely always use more. And as I said, a great designer who wanted to come into this community and help guide that would be very welcome. I'd love to talk to them, love to hear their thoughts. Somebody who had the focus and dedication to do just that would be awesome. Yeah, visual design would be especially welcome because I think our interactions are not too bad but our look is a little dated and generic. And it's, yeah, it is bootstrap with a few tweaks. So, definitely. Extensible in which type? Yeah, I mean the question was around extensibility of third-party dashboards. Should they be able to just plug in and work? That is entirely the goal. As I said, you can download the code from wherever you want as long as it's on your Python path and you add it to your list of installed apps in your settings. It should appear and work as long as the developer of the dashboard or the panel did things correctly. Yeah. Yeah, I mean, that generally exists today. If there are ways in which you need something more that I'd be happy to work on it. But as I said, I have built my own dashboards for my own uses to do all sorts of things and you can just drop them in. Was that, what's quantum features? Quantum features. As far as quantum features go, there's basic support for defining networks and subnets and then attaching ports, creating ports and attaching them to instances. So you can do all the kind of basic L2 networking. I'm not a networking guy, forgive me. That is what exists today. The higher level networking and load balancer stuff and all those pieces are what are coming from my understanding. But as I said, we've got a session on that on Thursday which is actually being led by someone from the quantum team so we'll get a much better view then. But the basic features are there. Two kind of related questions to cloud administrator functionality. Something that I've seen in other dashboards that I think would be immensely useful is resource serialization on each of the compute nodes. What do you mean by serialization? Resource utilization. Oh, utilize, I thought you said resource serialization. I was like, yeah. Yeah, absolutely. Versus free, bram, disk, et cetera. Right, the tricky part there is that OpenStack doesn't actually have a hardware layer at the moment. We don't have a lot of good insight into the actual nodes as far as what's going on there. We would need some support from the rest of the project but yes, I agree, that is a great sort of thing to do but it does tend to be deployment specific so making that generic would be the challenge. Dashboard adding some kind of a graphical representation of how much resources are free to run more VMs on each. As far as like the physical resources of your cloud, yeah. Yeah, post-mortem. And the other question was, is there anything on the roadmap for supporting migration of VMs? Oh, absolutely. As soon as that, actually the only reason that didn't land in Folsom is because it turns out it's only supported for the Zen hypervisor in Nova right now. If we can get full hypervisor support, add that in a heartbeat. That is a really high priority feature actually. It's just blocked right now. I thought that was supported in KBM. I believe it's, if the support has been added, that's awesome. When I looked in mid-Folsom, it was not there so it may have landed later on. I could be wronged. I could be wronged, yeah. We can both be wronged. Think there was some other hands, yeah, go ahead. That's a tricky question. The question is, are there guidelines for extending the actual components in Horizon, the data tables or workflows, things like that. There are thorough documentation of the actual components. The Python code is documented in line using REST documentation, Sphinx, all that. But as far as extending them, it's one of those things that there isn't really a way to tell someone how to do that. And without explicitly building in, when they're, okay, let me put it this way. When there are places that we've seen there are obvious extension points where you'd want to have a hook for another callback there or something like that. Those mostly already exist, those are totally documented. We can always add more of those. But as far as how to subclass one of them and tweak it into what you want, there really isn't a guide that I can give you there. That's, it's a challenging problem. I can always help people better understand how something already works or why it is the way it is. But as far as how to get it to what you want it to be, it's mostly a case by case basis. Other questions? Comments? Yeah. Dashboards and panels are both Django apps. Dashboard in particular can contain panels so they don't have to be separate apps. Dashboards basically just are rollups of panels. But yeah, if you, anyone who is familiar with Django should have no problem getting started. If you are not familiar with Django, the Django documentation is actually the way that a lot of people learn Python. It's that good. So go walk through their tutorial. It'll take you like half an hour and you will get it. It's really quite, quite simple. Great thing to know. Great introduction to web programming. If you're not a web or front end person, I really recommend it. I'm only like 50% of the code. Yeah, okay, baseline dashboard or a baseline panel. Like, do all the configuration for you. Like, you set up so that you can start making out the code. We're really hard to make it very easy for people to get involved. So please get involved. And just to add on to that, there are really, there are actually three, I was gonna say two. There are three ways that we need contributions. The first, which I wasn't gonna say is design. But the other two that I actually do wanna highlight are that you can help build the horizon framework that those core components, and those are the really tricky. You gotta get the APIs perfect so that other people can use them. But you can also build, like Trey said, you can build your own dashboards. You can build your own panels and contribute those. There's a lot of value there. There's a lot of territory there that has just not been touched because the core team only has so much bandwidth. So build a dashboard for your project. Build a panel that does what you need. Build a visualization that does that cool thing. That is the wild yonder where anything can happen. So that's the place where there's no, you can't get that one wrong. So jump in. They would like X, yeah. Absolutely, yeah. Anyone else? Okay, I think we're pretty much on time. Yeah, right on time. Excellent, thank you. It was great.