 So we're here to give you the Horizon Project Overview. It's actually been a little bit of, I think it's been two releases since we actually had a Horizon session at the summit, so there's a little bit of stuff to catch everybody up on. So a couple of introductions. First, I'm David Lyle, the ghost of Horizon Past and a little bit of a Dickinsonian theme. I was the Horizon PtL for five releases up until this last release, which was Newton. And here's Rob. Oh, I should say, I work for Intel in the open source technology center and it's been most of my time working on upstream projects. Yeah, I'm Rob. I was the PtL for the Newton cycle. I'm an engineer at Cisco. I should also give a shout out to Richard, who's the PtL for the upcoming cycle. Just raise his hand at the front. Yeah, it can be one. And we're glad to see he has the proper attitude for the job. I'm assuming if you're here, you know what Horizon is, but as a brief refresher, Horizon is just the graphical web interface that lets you manage OpenStack and view your resources. A couple of things to note, we don't have a database, so we've previously talked to the services on the back end. We mostly are relying on, well, not mostly. We have some core service support built in. Generally what we consider the classical core services in OpenStack, those listed there. We also have extensive plugins, a number of plugins out in the community. It's the numbers higher than I can track anymore, but I'd say there's at least 25, 30, or more separate plugins that will plug into Horizon. So, first we're gonna cover what's new. And again, like I said, it's been a couple of releases, so some of this is gonna be Metaka, some of this is gonna be Newton. Mostly because we still hear a lot about things that we did in Metaka that people don't know is there, so we'd just like to make sure everybody's aware of what's happening. So, one of the ongoing themes with Horizon is to move from the old Python interface to a client-side rendered AngularJS interface. The overall idea here is that we can stop rendering all our pages and HTML on a server somewhere, but pass it all over to the user and just pass data back and forth between the APIs. The first interface we swapped over here was the Swift interface. To give like a very quick run-through of some of the sort of improved responsiveness, this is the old interface. And this is just a local DevStack, so this is kind of really minimal latency type thing. But you can see that even when you're clicking through things, it's a whole page refresh. This is pinging the whole page over, this is pinging, sorry, an API request over, then retrieving the entire page after Horizon's rendered it all out. When you go onto the new interface, any navigation is just passing data back and forth, so you can immediately see kind of navigating through these folders how much more responsive that is compared to going through things here and having to click and wait, click and wait for something to happen. Moving into the Newton cycle, we swapped out the glance interface. So this has the same kind of effect. You can, looking at the old interface, you get the same thing where you click, you wait for Horizon to render a page, and this is obviously a much more dramatic effect when you're running this through a corporate firewall and around the world. But on the new interface, you're just passing data around rather than having to re-render these views every time and then pass them back to the client. So there's a dramatic speed of effect. Other performance improvements we've added, we've finally done a direct-to-service image upload. So rather than having to pass your data into Horizon and use that as a proxy to glance, with a bit of configuration, like some very small configuration, you can just use the glance server directly. So you no longer have browser-based limits when you're just trying to upload images. The other things that we've added is configurable filter requirement on an admin view. So when you typically view any admin view, any admin panel, I should say, within Horizon, you're making a great deal of data requests, multiple API requests across a great deal of data, and all in sequence. So that can take a very long time to return. And often, you don't even wanna see all of that data because all of that data at once is meaningless. You're gonna wanna search for specific things within that data. So what we did to get around this is to make these views require a filter before returning any data. So you'll load this panel in, it'll return an empty panel, and then you can just put a data filter in because you're gonna go there already knowing roughly what you're searching for anyway. The end result for the user is a much faster interaction on the admin views. And then finally, we added some template caching. So when you start rendering out views with hundreds of rows, a lot of that data is repeated over and over again. So things like each table row, for example, is a template snippet which is identical but just with slightly different data. So we now cache that. So if you're rendering out 500 rows, it's just retrieving that same row from the cache and populating it with the data. One of the ongoing things with Horizon is that we have to continue increasing our support for the various services and their APIs and new features. One of the long-standing pieces of work we've had going on is to support version two of the Glance API. I'm sure a lot of people here who are running Horizon will be familiar with the fact that if you wanna use Glance v2 features now, you have to run a Glance v1 endpoint anyway. And we had this sort of partial support where you could run mostly v2 but you still had to maintain a v1 endpoint. We now support v2 on its own. You no longer need to carry this v1 endpoint. And we support a great deal of the new features added in Glance v2. Another feature we've finally got round to doing is to make Horizon only depend on Keystone. So whereas before we've had kind of small issues and dependencies on things like Nova, you can now run nothing but Keystone and whatever service panels you want. So you can now do Keystone and Swift, for example, which is a relatively common use case to list out some other features that we've added. There's scheduler hints in the launch instance. We have a floating IP management panel inside the admin dashboard. And we've added things like consistency group support for Cinder. So we continue to push the v3 stone up the slope here. So we're improving our Keystone support. In Mataka we added domain scope token support. This allowed us to do things like have a domain admin, be able to manage users, the roles, and groups for their users inside that domain. It also allowed us to adopt the Keystone v3 sample policy file. Again, it's labeled a sample, but people are using it as the v3 policy file. So that gives us, essentially that defines three separate roles. One is cloud admin. Cloud admin is, I can control everything in the cloud. Domain admin, again, where I can control, I can manage the users and the identity items in a particular domain, but not outside of that. And so that was actually quite a bit of work. And when you log in now, if you're in a v3 environment with multiple domains, it'll ask you for your domain when you log in. Horizon goes out and tries to obtain the domain scope token for you. If it fails, it doesn't block log in, but that way if you do have a role on the domain, it'll pull that down, and then when you wanna do identity management, it'll actually do it seamlessly inside of Horizon. Because there's points where we have to, the way v3's designed is, you have to have a domain scope token to just to do the identity operations, but you still need a project scope token to do all the other service operations. And so for us to try and swap out tokens on the fly as we go would be prohibitively slow, so we just, we maintain both. And it allows us to gather some identity information while inside of more project specific views, like mapping an instance to a user kind of thing. We also added federation support. So you can do federated identity in Horizon now. That was actually, again, the Mataka issue, but we still get a lot of questions or feature that we added. We still get a lot of questions about that. So you can configure Horizon to talk to different federated endpoints, go ahead and log in and use it just as you had before. Along with that came some federation management. So not only can you log in, but if you have the proper roles in the identity dashboard, you can actually manage federation. So you can set up new identity providers. You can create the mapping. So when you're federating, you have to map the groups and the user values to something that Keystone knows about. But you can actually manage that through Horizon rather than having to go through a Keystone API or doing it manually with files. And all that actually gets turned on with just that one setting. So there's a minimalistic setting that'll turn on all this federation management. We continue to work on plugins. Again, like I said, we're moving to a model where we're mostly plugin-based, right? Most of our content now is coming from plugins, at least the new content. And so that's a constant area of effort for us to try and make that experience for the plugin developers as full-featured and seamless as possible. So some things that we've added, our client-side localization. So that's for the JavaScript. You can have localized text in a plugin and Horizon's actually smart enough to load that now. That was an issue before. We also added some client-side extensibility thanks to Ty and some other folks at IBM where you can actually extend workloads for, again, the JavaScript workflows by adding a step. You can actually specify the order of where that is in the workflow. Again, tables and actions are also extensible as well as forms. And then we've added something else for plugins to use. So we didn't have any settings support for plugins. So when somebody wrote a plugin and they wanted to have some configuration to base behaviors off of, we didn't support it. So we've added that. And that is actually the second column there, localsettings.d. So basically there's now a directory in the file system where you deploy Horizon. And you can just drop a small Python file in there that's just, it's the same Python that you would drop into local settings, but you can just encapsulate it into a small chunk. So when you go install the plugin and you have to drop your file in the enabled folder, you can also drop another file over in local settings to alter the settings. The reason we didn't combine it just in the enabled file is because there's also a use case where I don't necessarily want to write a plugin, but I want to alter behavior. So some distributions, especially when they do theming, they don't want it, they don't need a plugin because they don't need to add content. They're just, they're changing somehow some of the templates work, how some of the CSS works. And so they just need to manipulate the setting so that Horizon is smart enough to go look for that. I did just, I get this question a lot too. So we just want to, since we did alter settings, I just want to walk through how settings actually work in Horizon. So we have this overarching settings.py and really nothing should change in there much. You need to change a Keystone endpoint but it's basically a default. Almost, now I'd say 99% of the values in there are overwriteable and you can do that in local settings. So we set up a bunch of defaults and then in local settings, you can go ahead and override those values. So settings comes along, it loads local settings and beyond that, after it does that, then it goes in local settings.d and it loads all those little snippets. And so it's building up these settings as it goes down and then we load themes and we load some ecstatic packages which is not very exciting. And then we load the plugins and this is a green because you can also affect settings in a way there. There's one little chunk of settings called Horizon Config that you can alter inside plugins. It's legacy from our original plugin implementation. It's fairly limited. The better way would be to do it with a local settings.d snippet but you can include it in the enabled file. So there's multiple places where you can affect settings and not really have to touch the settings.py file for almost any reason. So we've also been working on usability a lot. Usability is a very important issue obviously. We're here to try and make OpenStack a lot more accessible to users. And so just some of the broad things that we've covered and then we'll actually take a look at it since we're a graphical UI, we might as well actually look at the stuff. But we've done a lot more API filtering. So, let's see if I can go over here. Rob needs to lengthen his timeout, I believe. So I can, now, actually instances is probably a poor example although we've made this more complete. We had this on instances before but now we've, I think there were four fields previously now. There's basically anything the API will support filtering on and will support filtering on. So previously in Horizon, that search bar just did a local search on the page. It did the content that you had rendered on the page and it was a worthless search because you can do that with control F. So doing it on the server side means that we're gonna actually pass this on to Nova when we go across the data for the page. So we're gonna say we want Nova to actually filter by these things and so it gives you all the possible values here and then I can go filter for server one, something exciting like that. And obviously, since we have two on the page, it's not gonna be, but in this case, it's not that great of a help but you can envision if you had 500 instances being able to reference by name. Certainly helps you to filter it down. The other thing I'll point out on this page is so we have consistent breadcrumbs across views. So you always know where you are. Before we, I think we had sporadic breadcrumbs in a couple of details pages and it was often hard to know where exactly you were in the hierarchy because our navigational kind of dig down a little bit and this gives you a clear path of how I can get back to where I was. And then in the case where, in case where we go down to the detail view, these start to become links and so I can go back to the base view. These other ones aren't links just because those links are right here. So another thing that we updated, un-updated, real-updated is the network topology. So a couple releases ago, we switched over to this more graphical view of network topology. And for large network topologies, this works really great. And we can hover over, oh, we guess we click in this one. Sorry, one of them's click, one of them's hover. We need to fix that. So we can click on this and you can get more information about it. But it's not a lot, a lot of the information's not as readily accessible again because this was built for scale. But we got some feedback that people, people like the old topology for certain reasons and for certain use cases. And so now we can actually take the same data and we just share a data model and render both ways. So, I mean, this one obviously provides a lot more information up front. And so for a smaller topology, this works again, trying to map all that on a graph with 1000 nodes is not gonna work very well. So you now have this choice to be able to switch between the two. And then D mentioned admin filter first. But again, this is a usability and performance issue but this is just a screenshot of what that looks like. So you get dumped into the page and you get this message to say you need to enter some search criteria. So we try to make it as clear as possible to the user that they have an action that they need to take. Another part of what we've been improving over Horizon in the past couple of releases is to address consistency issues and branding and theming across Horizons. Branding and themability, I should say. Nearly one of the first questions we had every single operator's session for like every single summit I can remember was someone would raise their hands and say, every single release you've broken all of our CSS, we have to get someone to sit there for two days and fix it. We spend a lot of time now addressing that. We have some really good documentation. We have dropped everything back to the framework that we use, the CSS framework that we use, Bootstrap. So we basically use the default now, the default coloring, the default paddings, everything like that. So that you can now write your own style sheet in the way that Bootstrap recommends in its own documentation and then just carry that from release to release. And as we add new content, we just inherit those values. So there's no more of this consistent hacking that you have to do every single release because we've changed something and now this button is off the edge of the screen. You can just consistently carry the same piece of code between things. So a quick demo of one of the things we added whilst doing this is switchable themes. So you can have the, I'll just show it, it's much easier. If I go on to the Swift panel, these themes are just configured in settings and you can toggle on the fly between them. The only downside is a very small increase in the amount of time it takes to compress your static files but that's like a one-off deployment thing so it's barely an impact at all. But this gives you a great deal of flexibility because you can start doing things like accessible themes, for example, for people with colorblindness or issues with reading dark text on bright white backgrounds or something like that. And it also means that you can import from these themes. So we've added material theme which I believe I've got running here as well as the BootSwatch library which comes with a load of preconfigured, something like 20 different preconfigured themes. And you can import, you can inherit from those, I should say. So you've got a lot of flexibility in how you build out your own branding and stuff so that there's a good deal of examples in those BootSwatch themes. So now you can kind of reliably configure all of the branding and theming across horizon and we'll just continue to inherit it. So to go through these things you can look at different panels, for example, and you can see how it's all just inherited all the colors, all the padding, the fonts. It just works for lack of a better phrase. So another thing that we've done in the Newton timeframe is update the policy files. So I originally implemented the policy support in Horizon several releases ago. Unfortunately the way the policy works inside of OpenStack we have to have a local copy of the policy file and so we bundle those in by default. You can change them out as you wish but just the static copies inside Horizon weren't up to date so we made sure we updated that. When doing that we found some services had changed the way they used policy so we made sure that we could support this new utilization of the policy rules. Neutron is specific, did a little toggling back and forth on the way it did it. So but it should work seamlessly now and it'll support the old method and the new method. Now with more policy. So we've actually added a few more policy checks on views to guard them against people, not showing views that you don't have access to do anything on. So we continue to try and hone that and make it as complete as possible. Some of those guards were related to the V3 policy file support that I mentioned earlier but there were other checks just to guard image different views so that the users don't get places they can't do things. Yeah and like I said Keystone V3 policies that was not a small effort but the support is there at least for the three main rules. We made it so it's not hard coded so that you can actually edit the policy files and it should just work. Policy is a fun thing to edit on a large scale. Small switches are fairly easy to pull off but if you ever run into an issue obviously feed it back to us. Okay, yeah the boring bits, this is my favorite part. So one of the big advantages we have as a dashboard as a UI is that we can start adding developer tools to help people do their job day to day that are graphical themselves. We don't need to just have documentation and examples we can have very literal like user interface examples. So I think in Mataka we started adding the developer dashboard and there's a couple of things in here and there's a couple more in progress which I'll talk about later. So in here at the moment we have a theme preview which is basically what we use to demonstrate that the CSS that you're writing is functional and that isn't breaking things. So this is a collection of all of the bootstrap and horizon components. So most of these are kind of standard bootstrap and as we scroll down there's examples of like specific horizon components, things that we've made themable like check boxes and radio buttons, things like that so that people have greater control over the way their interface looks. And as you again if I go back to the theme changes you can toggle this and it will swap everything out immediately so you can see how everything looks. So you no longer have this issue of fixing one thing in one place and not realizing something else is broken until someone shouts at you two days later. Everything's on one page, it's there and demonstrable. The second part that I wanted to talk about was that as we go through and add more AngularJS pieces of code we've built out this registry which lets you create generic views without having to hard code all of these tables. So this means that you can effectively register a bunch of different properties, the phrase we've settled on here and table columns and then when you make your API call it will just give you a generic table formed from a single view. And so to help with developers building this out we've built this resource registry that demonstrates this. So here you can see all the different columns that have been registered, all the different actions that we've registered for an image for example, and even build out the generic table live. So that's just built from saying, oh well I've made a list call, now I wanna show these seven columns and that's just a generic view with those seven columns for this images list call. Which has been an ongoing effort and the end result's really, really cool because it really reduces the amount of hard coding of what these things look like and really we are just saying, I want a table and I want it to have these data points and here's my API call go and it'll spit out this table for you which is consistent with the rest of Horizon and consistent with the theming and branding efforts. I kind of spoken a bit about that so we've done the same thing for the details pages. Again if I go back to here, this is the same thing, it's all composable with this registry. At the end of the Newton cycle we added in a library that lets you do a similar thing with forms and workflows so you can now define them just with a JSON blob and just that data form will kind of spit out a multi-step workflow and we're in the process of adding another developer tool for building and demonstrating those. The idea here is that people can build plugins, people can build their downstream customizations without needing to have an in-depth knowledge of how Horizon has implemented a lot of this stuff so rather than having to write out your forms field by field you can just say I want a name field, I want an IP field, whatever. It needs to be a string and Horizon will spit out a form that has those two fields that it's translated. It's consistent with the rest of the UI, the branding is all inherited and you don't really need to, people don't need to know a great deal about this to make that happen. And finally, we've had, I wanted to mention this because it was quite a big effort to get this stuff done but we've made a concerted effort to keep on top of our ecstatic dependencies. So ecstatic is how we package up most of our third-party static assets. So over the past release cycle we spent a great deal of time adding a new release mechanism to make this fit well with the rest of OpenStack so that you get properly published releases and also bringing a lot of our dependencies up-to-date with the latest stable release. So most of the CSS and JS things now are up-to-date with their latest master release so that we don't have dependencies that are lagging many months or years behind current releases. So what's up next? We're gonna continue with the client side move. We want to hit performance issue places, basically. So panels that traditionally have larger scale, things like the instances panel where you may have many, many thousands of instances and identity panels, so user and project management, those could really benefit, especially places where you have limited server-side filtering and things like that. We can start moving some of this data onto the client side and start trying to improve the usability of it. We're also currently looking into doing improvements to our quotas. So at the moment, a lot of our quota stuff is pretty hard-coded and there's not straightforward ways to extend this for other plugins and services. So we're looking into extending that. And then finally, for my part, at least, the developer dashboard, we've got a performance profiling panel in the works, which will let you go to any view within horizon, click a button, and it will just spit out a list of all the API calls and how long they took. This uses a library called Osprofiler, and as that library develops, they're gonna work on putting these profiling points into the services themselves. The idea is that you could go into the instances view, which is taking a ton of time to load on your cloud, hit this button whilst you've got your developer tools running, and it will tell you exactly which API calls are taking so long, and hopefully give you a better insight into why. And then, as I mentioned earlier, the workflow builder. So this will let you live code and live test multiple-step forms and workflows and view it side-by-side with this code as you edit it. It has a ton of examples as well. So you can bring up an example workflow, customize it a bit, see exactly what it will look like, and then hit a button and it will spit out the config for this, and it really just helps increase the pace at which plugins and deployers can add new content. And then we have continued identity work. So again, V3 is a large change and it continues to change, but we need to further refine our Federation support. We have, like I said, we have Federation support. There are nuances that aren't strictly supported, so we need to put more effort in to making sure that we support more of the corner cases and even some of the variations that people are trying to do now. And then we're also looking at K2K as Keystone to Keystone Federation. That's been something that's been in the works for a while. I think we have a plan for this release that we're actually gonna be able to get that in. Again, that's using Keystone to federate between different open-stack clouds. So there's actually a lot of people asking for that feature and very interested in it, so I'm excited to get it moving forward again. We're gonna more policy handling or refinement. So there's a lot of nuance in, especially the V3 policy in Keystone. And we can certainly handle improving how our handling of that. There's, again, there's some nuance there that needs to be thought through a little bit better. So that'll be a focus moving forward. And then, as always, we just are trying to keep up with the rest of the open-stack services, at least the ones we support in Tree. They're moving at an amazingly quick pace and it's difficult for us to stay in sync. So it's an effort that we do every release. Like Rob said, we got Glantz V2 in this time. We had Cinder V2 in, a release or two ago. But it's not just whole API versions, but there's aspects to a lot of the APIs that we don't fully support yet that you can't use in Horizon. So we're gonna continue to push on that. More Horizon, meaning if you wanna participate, if you have a problem, if you have questions, these are some of the places that you can go to to get help. We'd love to get any bug reports that you have. Seriously, that's the best feedback we can get if you've run into a problem. Please just file a bug. We're not gonna be reactive in a negative way. We really want your bugs. We have a very active channel on FreeNode in this open-stack Horizon room. You can always come and ask a question. We have developers in Australia and England and the United States, so there's not a time that somebody's not on there. I mean, we have holidays and things like that, but it's a great place to find somebody and have a live conversation and not have to wait for an answer as long. We have docs, we have release notes, so some of the stuff we cover during the release notes, but it's tough to always figure out the grand feature from the release notes. If you want to develop, we have a developer page. Again, FreeNode's a great place to go for that, too. We have how to get started docs, and if you want to actively participate, we have meetings, team meetings. Those happen on IRC as well and open to anybody, so feel free to drop in. I think that brings us to the point where we will, if you have questions, we'll do our best. Cool. Solved it. Oh, yes, there's probably, no, there's not mics. I'll repeat the question. I would say yes, so we recently replaced the SwiftView. It's still an active area of interest and development, and so we would definitely like to continue broadening the support there. It's been a pain point for a long time, and if you really step back and looked at the old Swiftee interface, you'd want to tear your hair out. So we're making progress, but yes, we'd love to continue to work there. One of the, Richard actually did the work on the SwiftUI, and so since he's now in charge, I'm sure that... To tag onto that, there are things now in the SwiftUI that not only is it massively more performant, but there are a bunch of features in it, like the recursive nested delete with sudo folders and things, that weren't in there at all, and that's a really fluid, really well-built part of that panel now. So yeah, we're definitely working on improving it more. Can everyone hear Tim? So the question was about large file support, and then Tim answered, and he's one of the core developers on Horizon, that there's a patch up to handle that in a... Then the question was about both dynamic and static objects, and we all drew blank faces, so we need to brush up on our Swift a little bit. If you want to hop into the Horizon channel and tell us more about what we should be adding, that's great. We would love to have it. Like I said, all contributions are welcome, and yeah, Swift is something we'd love to improve on, so yes, feel free to jump in. So to reference the other thing about contributing to Horizon, we don't always just need people who want to write code for Horizon, it's just about the knowledge sometimes is difficult. Like if we're managing panels for the six core services and a couple of others, plus their extensions at the moment, just getting the knowledge for people who are web developers and also have a deep knowledge about a service at the same time, there's not that much of that cross-project knowledge, so if you have a feature that you want added, we're not necessarily asking for you to code it yourself, but really just hop in and tell us how this thing works. Maybe walk one of the developers through the API and explain the intent and what a good interface would look like, and we can definitely help build that out. So, yeah. On ISE, yeah. Free note, or even a bug telling us that we don't support this is, I mean, it's a start, it's an awareness, and we can work from there. I mean, you'll have a user ID that's assigned to that, so if we have a question, we can come back to you and say, I don't really understand this, and we'd love to find out more, but yeah, that just give us, I mean, so we try to follow all the services, but again, we can't keep up with everything, and so, yeah, the best way is somebody to come and tell us, hey, we have this new feature in this service, or there's this part of the service that you're missing. You should really think about implementing it, and we're like, oh, I didn't know that existed, that's great, well, yeah, let's get on it, yeah. Thank you. Any other questions? All right, no other questions, thank you very much.