 I'm David Lyle on openspec-wordptl. I just want to start off with even the next slide. So I just want to start out like a lot of these reminding what our mission statement is in Horizon basically to provide an extensible unified web-based user interface for all integrated open stack services. So we want to be a unified user interface for all the open stack services that are integrated into the release. Obviously with the big tent discussions that scope may creep out a little bit, but for now that's still the range of what we're trying to accomplish. And then the other big item is we want to be extensible, so we realize that we can't deliver all functionality that you would need to operate a cloud or provide your end users via Horizon. Every cloud I know of runs other extensions, other things that they want to manage, so we want to be able to have that extension mechanism so that when you go and set up a cloud then you can plug in other functionality into Horizon. So just a little recap on Juno. Some of the big additions were support for Sahara. Sahara came out of or was added to the integrated release in Juno. We have rich support for creating clusters, creating jobs to run those clusters, to do MapReduce and other data processing operations. So that was a big addition for us in Sahara. There's a lot of functionality there, and I encourage people to check it out. Better plug-in support. We had a primitive plug-in support mechanism that we added in Leap Ice House. In Juno we flushed that out a little bit better, allowing you to pull in more of your static files, things like JavaScript images, other things that allow you to do a more full-featured extension. This also helps operators move away from the model where basically you have to pull down the Horizon repo and then hack the code inside of Horizon to extend it. That's really not a great model for anybody who's trying to deploy code and then keep it up to date with Trunks, so we've been working hard to provide a better mechanism. The next item that we did was UX updates. So we kind of walked into some older technology, some older versions of Bootstrap for our styling and JavaScript and other things. We finally got past that so we can pull in a lot of the bug fixes from upstream, a lot of the styling improvements, a lot of the UX improvements. So now we're currently up to date with Bootstrap and a lot of the other underlying libraries that we were dependent upon and so that's been a great step forward. The last big thing I'd like to point out is Glance added the metadata catalog concept and the general release and Horizon provides support for both viewing and updating metadata properties on things like images and volumes and post aggregates. And so we provided a nice widget for that and that functionality was added in Juneau. There'll be further enhancements of that in Kilo. So what's next on the deck for Kilo? So the first item is going to be support for Ironic. So Ironic graduated in the old mechanism, again with the big tent model, things may change, but we plan on supporting Ironic in the Kilo timeframe both for end users and also for operators. So end users will have the option when interacting with nobody to set up a bare metal instance rather than to have that option and then operators as well to both specify new nodes and then bring them in allocation. So at the summit we spent a lot of time talking about how we were going to provide a better user experience going forward. It's been a big focus of mine since I became PPL and trying to take Horizon and make it a lot more user-friendly. And so about a release ago we decided to start moving towards AngularJS as a more of a client-side architecture. The reasoning behind that is just to provide better feedback to users quicker. We tried not to do so much data loading on each request, so push a lot more of the UI onto the client-side, cache data there, and be able to operate on a lot more data and provide that information back to user a lot quicker. So in Kilo one of the first things we're going to do is work on a reference implementation for how Horizon is going to move forward in this transition. The focus of this will be on the identity dashboards or identity dashboards, so panels like projects and users. And when you bring in Keystone V3 you'll get groups and roles and domains. And so this basically will use that as a way to set up the reference implementation for going forward on how we're going to use Angular and how others can use it in extensions going forward as well. Part of the improved user experience effort that we're working on is improving the table experience. So right now the state of the... Each server has different APIs and Horizon kind of thinly represents that API to the user via a list or a table. So the filtering's inconsistent currently. Pagination is inconsistent. The different APIs do different things with pagination. They provide different filters, different ways to search, essentially. So what we're going to do is we're going to move a lot of that onto the client-side as well. We're going to try and cache a bit more data on the client and provide the pagination and the filtering in the Horizon code rather than relying on the APIs to do it. In that way, we can provide a consistent user experience. So the user doesn't have to guess if they're moving through the Horizon UI and landing on a new page and trying to figure out what the paradigm is for this page. So again, this is just trying to improve the user experience but more information at the user's fingertips and allow them to find data a lot more quickly and accomplish the tasks that they're trying to do. Additionally, as far as the user experience, so we implemented a wizard. I believe that was back in late Havana. I thought that kind of that stagnated as we were trying to move forward but it's a primitive wizard. So a step workflow, essentially. We're going to refocus on that in this release. Part of that is with the Angular implementation. So in this release, we'd like to get the launch instance workflow or wizard greatly improved. That's one of the biggest usability issues with Horizon right now is that the launch instance workflow is just very confusing, requires a lot of knowledge up front. So we've been working with the OpenStack UX scheme for the past release essentially on design to get a better workflow on that and move forward. Part of that, that'll be implemented on the client side as well. And so we want to make sure that we're not kind of pinging ourselves into a corner on the implementation. So we're going to do the network wizard as well just to make sure that we have an extensible format, extensible widget on the client side that we can reuse. We're going to continue to refine the plugin support. As I said before, it's really important that we have a clean plugin mechanism that doesn't involve editing the source code in the Horizon repo in any way or the Horizon package when it gets shipped. Right now, the plugin mechanism does require you to add files into the directory where Horizon gets deployed. Obviously, that's not optimal, and it causes a lot of problems when you want to go and update a package if you're doing it with a packaging system. So we're going to continue to refine that so that you can point to where that plugin mechanism is. Again, and then we're going to have to refine a little bit to provide better Angular support as well as we're moving more in that direction. Better theming. So another big concern for operators is that they don't want to ship Verizon looking the same as everybody else's UI, especially if you're putting it in front of customers or you're wanting to do refiller models. We need to be able to theme it better. We need to be able to do that without hacking into the Horizon code so the rule for this is we started down this road. We started pulling out the appropriate variables for coloring and size that operators want to change to change the look and feel. We're going to continue going down that road and provide hopefully a much better theming mechanism that's a lot easier to leverage. Federation and single sign-on. So we're working with the Keystone team to provide federated authentication. Obviously, a lot of corporations that use OpenStack have an authentication back in already where all the users are set up. They don't want to have to pull that into Keystone or all that user information into Keystone. They don't want to have to duplicate all that. So we're going to provide the federation a mechanism to do that federated log-on. Come along with that single sign-on where hopefully if you're authenticated into your corporate authorization system already, then when you come to Horizon, you wouldn't have to re-authenticate. Multi-domain identity operations. Keystone v3 has been out in Savannah. Actually, yeah, I think it's Savannah. There's support for multiple domains in there. We support that to a degree in Horizon. We need to do a much better job. Part of that is you want to have a much richer set of roles than admin and member to do these operations. You want to have, say, a domain admin. We can't really support that right now because we don't interact with Keystone the right way. So we're going to tackle adding that support in this release. So that should provide. This will be a step forward also on the hierarchical multi-tenancy path at the Keystone implementing in Keylo. So this work will be leveraged in that as well as what's already there in Keystone v3. Another big thing that we've been pushing on for a couple of cycles is getting integration tests going. So for the long time, Horizon had just unit tests. We had one integration test that ran in Tempest. It still does, actually. But we've been working heavily on trying to get an integration test suite set up and going. So we actually have quite a few integration tests that run against the Horizon gate jobs now. They're not as big as part of Tempest because we're still trying to work through the kinks and get it more full-featured. But I think we'll be ready with that at the end of Keylo to be able to run all the gate and jobs, at least for Horizon. And that is all I had for Keylo. We'll continue to finish fleshing out API support. So Horizon has pretty good API support across the open stack, but there are certainly parts of the API that we don't represent. And as services move forward with the versions of the APIs and adding features, obviously we like to pick those up as well as we move along. So that will also be, I mean, that's a consistent focus of ours is to try and remain in sync with the other services. And you can feel free to contact me on free.irc. That's David's type in Lyle, or you can email me at david.lyleandintel.com. We have weekly team meetings. The time is off late, so it's best to check out the open stack meetings page if you'd like to join in and provide some feedback or ask questions.