 The webinar series, these series evolved from sessions that were held by the PTAILs regarding updates to their projects at each summit. We converted them into webinars to extend the reach of these events beyond the summit. Today our PTAILs are going to update you on what may be new for Juno, as well as detail any other items of note for users and operators. So we're joined today by David Lyle with Dashboard and Kyle Mestri with Networking. David is going to present first and then Kyle. So, David, let me put your presentation, presentation mode and there you go, when you're ready. Thanks for the introduction. Yes, so I'm David Lyle. I'm the Horizon Program PTO and today I'll just give you a little bit of an update on what we're looking at for features for Juno. First one to start out with, so recently inside OpenStack, we've tried to get all the projects to be a little bit more unified on how we represent ourselves and details about it. One of those items of consistency is having a mission statement for each program. So just wanted to start out with the one for the dashboard program and here it is, to provide an extensible Unified Web-based user interface for all integrated OpenStack services. So one of our key goals is extensibility. We realize that whatever we deliver in OpenStack Dashboard is not going to be enough for most operators out there. It's good for a proof of content platform but there's going to be, you know, either proprietary features or extensions that people want to load in. If you're running a public cloud, you're going to need something about billing, you're going to need a lot of different monitoring, that sort of thing. So one of our primary goals is making the dashboard extensible so that companies that pull it down and want to use it can add those extensions and those modifications, do a little bit of branding as well to provide a user interface that will work for them. I also want to point out that it's a unified Web-based, so the unified part is saying that really we don't want a bunch of disparate user interfaces across OpenStack. We're trying to have the services managed in a singular graphical user interface. Obviously the CLIs also exist and the APIs are available but as far as the graphical user interface, we want them to be in one unified piece of software. And then the last piece is where we're supporting all integrated OpenStack services. So there's different stages in the life cycle obviously of becoming part of OpenStack and we don't pull them into the Dash, pull these, or support the services in the dashboard until they are integrated but at that point we definitely do want to have support for them in Horizon. And along those lines, so one of the key features for Juno is Sahara has come, the project has completed incubation and then graduated and become part of OpenStack and so we want to integrate a lot of the great work that the Sahara team has done on Horizon component into Horizon proper. So they developed it alongside Horizon and right now we're in the process of pulling support for Sahara and so you can manage your Hadoop clusters from Horizon in OpenStack, so that's slated to be here in Juno pretty quickly. So another large item that we're working towards is a richer user experience. So we have a large amount of API support but we really want to focus back on making that API support usable and so there's some areas we're concentrating on for most users of Horizon, the primary use case is I want to launch an instance. Right now the workflow to do that inside of Horizon is a bit cumbersome and you have to have some knowledge beforehand to be able to complete that task. So we're taking a critical look at that, we have been over the past, I'd say six months, we actually did some usability studies that were presented at the OpenStack Summit to find the pain points there and we're going to rework that interface to allow users to more easily be able to get their instances up and going. There's some other things that we want to add in for user experience, one of them is the richer filtering, so do more API-side filtering, this becomes a mandatory for anybody who has a larger installation or for admins, being able to find the information they're looking for in Horizon right now is somewhat hit or miss, we want to get that unified and then provide that to admin users. Pagination is also somewhat hit or miss, so we want to get that unified inside of Horizon as well, again to support those larger scale installations. Validation, so we want to be able to do more input validation for forms when you're trying to update items in Horizon, so we want to be able to provide some client-side validation for that to give user better feedback and quicker feedback without having to make round trips to the server to figure that out. And then the last item here that it's not listed, but we also want to focus on accessibility, so we really want to make Horizon a product that companies can pull down and use, and so one of those, one item there that is lacking in Horizon right now is accessibility for screen readers, and that's the big thing right now, so we want to be able to support screen readers out of the box and allow, you know, there are restrictions on web software that certain companies can't use that if it doesn't support those requirements. So over the past two releases we've been working on, role-based access control support inside of Horizon. Horizon, from early on, has supported basically two roles inside it, it opens back member and admin, and that's it, those are the two user roles that you could have. We've been, over the past couple of releases we put in a policy engine inside of Horizon and we've started rolling that implementation into the different panels and tables that we have inside Horizon, and this release we're trying to take the final step where we can actually turn that on and allow more diverse roles going forward, and also trying to consolidate some of the views so that it uses that role-based access control to show you what controls you have that you can use and hide the ones that you don't have access to. And an ongoing effort in Horizon is to increase the API coverage, so we have, we cover a lot of the APIs from the different services, the services are always moving forward and that's great, obviously it makes our job challenging to try and keep up and so as we move forward we're going to try and increase some more of that and we have blueprints to cover many features that say in Trove that weren't, that were added in Juneau, but we don't have support for them in Horizon yet. Cinder's another big area that we want to, that we have a lot of blueprints to focus on that API disparity, and then across the other services as well, we have a lot of work out there to do and a lot of great people picking it up and contributing to Horizon. So behind the scenes we're also doing a bit of a retooling, we're going to split our repository. So right now we basically have a toolkit inside of OpenStack and we have the main application that causes us some issues and so we're going to split that out and the other benefit of that is a lot of people like to use the toolkit by itself to build web applications or future dashboard elements that would come into Horizon as they come out of incubation. So this will aid that process going forward, they won't have to pull down an application and a toolkit to be able to do that development. It also helps, because Horizon is kind of a weird case right now, they don't fit the mold. So this is a lot of behind the scenes work, but it's a big priority for us to tackle in this release. We're also working on an integration test suite. So Horizon isn't as tied into, it's tied into the gate like all the other services, the gating mechanism for code to merge, but it's not, it doesn't have much in the Tempest test suite right now. So we're working on a set of, last release we added an integration test harness inside of Horizon and now we're adding, we're trying to build out that test suite and get it stabilized to the point where we can get it included into the automated test runs. And that's all I have for you today. Great, thank you. Does anyone have any questions? If they go off to see, not yet, okay. All right, let's go over to Kyle then. Thank you, David. And then we'll see if we have any at the end. Okay, Kyle, so when you're ready, all set. Okay, perfect, thanks. So good afternoon or morning or evening, wherever everyone is. My name is Kyle Mestri and I'm the networking PTL in OpenStack now. So I, these, I think we'll just do the similar thing that David did, basically go over some updates for OpenStack networking for Juno. And like David did, I think a good place to start is, is with the mission statement that each of the projects have. So for networking, this, this is our, this is our, this is our mission statement. And one of the things that we've done in networking to, to kind of achieve this is, you know, Neutron is, is a pluggable interface pretty much up and down through everything. So all of this is implemented through, through plugins and drivers as well, both in-tree and out-of-tree as well. And that's one of the things that's served us pretty well. We have a large, large number of plugins, both core plugins, ML2 mechanism drivers, service plugins for the different services we have as well. So it's, it's, it's actually served us as a project pretty well. So I, I thought what I would start with for people here is, is to note that, that we do, one of the things I did after the Juno Summit was come up with a project plan. When, when we were in Atlanta for the Juno Summit, we, we as a project, you know, had, had two and a half days of design summit sessions. And after that, one of the things I really wanted to capture was the high-level community, the tasks that were important for the upstream Neutron project. These were, these were the items that, that I felt should be captured in a project plan and documented so that people had some visibility into where some of these things were going to land in the, the milestone releases, Juno 1, Juno 2 and Juno 3, and which would ultimately be in the release. And, and I think most importantly it was, this has really helped us as we interact with distributions, with, with the people who are going to consume the upstream release and distribute it, whether that's Red Hat, Canonical, Mirantis, Rackspace, whoever else is, is doing that. This has given, this has really helped them I think by giving them some visibility into when things should land and things like that. So I think I've been pretty, pretty happy with this. And I think that I've gotten some good feedback from others. So there's a link in here in the slide if people want to go take a look, because what I've tried to do in this presentation is highlight some of the bigger ticket items. There's a lot of littler, smaller items that are in this project plan as well. So let's, let's jump right into, you know, what we're doing for Juno. This, this was the number one item that the Neutron has taken on is achieving parity with Nova Network. And we, we did a lot of work as a team in Ice House to lay the groundwork for this. And we're still, we're still finishing this off in, in Juno at this point. We're going to, the plan is to, is to officially close the gap with this and to move forward here. You know, we had, we have a plan that's been blessed by the, the TC as well that we're working on as well. A lot of people are focused on this and this covers everything from database migration stuff to migrating from Nova Network to Neutron, to implementing Nova multi-host mode and things like that. I think one of the, the big things that we're looking to do here is to start off with a migration script which will allow existing installations running perhaps Ice House with Nova Network to be able to migrate to, to an equivalent Neutron functionality for Juno during that upgrade process. And that's something that we're working on now. We don't have any, any sort of scale numbers at this point as to what we're going to be able to support there. But it's, it's something we're very actively working on right now. So the other main item that, that we're working on for this is actually on the next slide. So yeah, distributed virtual router. This is, this is the feature that will allow us to implement the Nova multi-host mode. And so what this does is, this is going to implement L3 routing across the compute nodes for the east-west traffic there. It's also going to, it's also going to implement floating IP namespaces per compute node as well. So for those features, you will no longer have to send traffic to network nodes. You'll be able to do this on a per host basis. This, this is the equivalent of what Nova Network multi-host mode was doing as well. It's, it's worth noting as I, as the third bullet says that the SNAP traffic is going to remain centralized, but there's, there's another feature. And the only reason that that's the case right now is because that's going to be a further improvement post-juno to try to distribute the SNAP functionality as well. The problem with doing that right now is the, the amount of IPs you have to burn on those public networks for that. So that, that's something that we're looking at doing post-juno. We, we are going to improve the situation around the network node with regards to HA by there is some work going on to, to implement HA for the network nodes using a VRRP as well. So this, like I said, this is, another big item with this has been, has been testing this functionality right now in the, in the gate when commits are pushed up, there, there is no multi, there's no multi-host testing that goes on for those types of commits. For something like DVR, the functionality to be able to, to test commits with multi, multiple nodes is, is actually pretty useful. So that's, there, there is some work going on to explore that functionality and see if we can implement that in the gate as well. Besides that, there's a lot of organizations that have volunteered to help test this DVR functionality at, at scale. And so we're working, we're working around that to, to ensure that we have this tested as well. So the next slide here is around DB updates and migrations. This is also something we are going to, to fix in Juno and address. The problem we had beforehand was it turns out that our database migrations were not item potent such that they were dependent on the plugins and the service plugins that you had implemented in your installation. So we're actually going to implement the healing migration in Juno and from Juno forward, all of the migrations will include all the tables for all the plugins and service plugins and such. This will provide a much more consistent experience for operators as well and should make things much easier if, if installations end up changing, changing plugins or adding plugins or, you know, mechanism drivers or service plugins or things like that. So I think this is a, this is something really useful for that. Another, this has also been a big focus for Neutron, third party testing and CI infrastructures. And this really started in ice, in the ice house timeframe as well. And there's a little bit of history behind this. You know, when, when Neutron was first started back when it was known as quantum, we, we originally had a small number of plugins upstream and the requirement was typically, you know, a plugin would have a core developer upstream as well, kind of shepherding it in addition to working on community features and the rest of the code. That, that didn't scale as well because it was hard to find that many core developers that fast. We ended up with a deluge of plugins and so that didn't quite work. So in ice house, what we did was we, we started to mandate third party CI testing and we put in place some requirements around it. Most people got the CI systems up and running and what we're doing in Juneau is we're actually continuing that by, by trying to come up with more consistent experience for developers and, and by developers, I mean people are submitting patches, possibly see them fail on other third party CI systems. We're trying to come up, make sure that people are following a consistent way of using the, the tools around this. So the developers have an easier time to look at failures there as well. And it also, the other nice thing about all of this is it provides consistent testing for all of the entry plugins as well. That's, that's really, that's really what the main focus has been around here is, is to try to improve the quality and things like that. What happens with Neutron is a lot of the plugins may require either some sort of hardware, which is not around, or even some sort of virtual machine to implement the networking abstractions. So this, this allows the vendors and even the open source plugins to, to implement that third party testing on their own infrastructure, wherever, you know, in their own lab or whatever. It's actually been pretty successful. And I, you know, Neutron has the largest third party CI testing setup upstream. And then one other note on this, there's actually a meeting on IRC on Mondays around this where we're trying to let all of the third party plugins and CI systems developers and owners exchange information, ask questions, and that's actually been fairly successful as well. So the next item I wanted to touch on was, was Elbas or a little balancing as a service. We, we as a Neutron team have spent a lot of time on this, even leading up to the Juno Summit and post the Juno Summit. And so what the result of all this is that we're going to, we're going to unveil a version two of the Elbas API in the Juno timeframe, a brand new API with a new object model. We're, we're going to, we already have work underway on the API and the object model. And in addition, there's work to update the Intree HA proxy driver so that it will reflect the new API and the new object model. I think one of the more interesting things here is that in addition to the Intree HA proxy driver, there's been a group of companies that have decided they're going to start a new Stackforge project called, which they're calling Octavia and this is going to be an operator or carrier grade implementation of load balancing in Neutron. It's, you know, the nice thing is they've been involved with the new Elbas APIs in Neutron. So they're, they're pretty excited about those. And, and by doing this Octavia project on Stackforge, it allows them to kind of iterate at their own pace outside of Neutron, but tying themselves into the Neutron Elbas APIs. So I'm pretty excited to see the result of Octavia once that happens. So I also wanted to touch base on the group-based policy API work that's been going on in Neutron. This, this is an API, it's an extension API to Neutron. And this, this is going to provide a declarative policy driven model for, for people that's really application focused. This, this work started in, at the Ice House Summit in, in Hong Kong was when it was first presented. So the team's been working on, the sub teams have been working on this since then, and, you know, the work was, was approved for Juno and is, is ongoing right now. So this is, this is something that some people have, I actually won't take credit for this quote, but someone, someone mentioned that, that this could be, you know, Neutron's porcelain APIs to go along with the plumbing APIs that exist already. So, so we'll see, but this is a, this is looking pretty promising and, and should be pretty exciting as well. So the next item here is something I alluded to when I was talking to the DVR functionality previously as well. And this is a HA for, for L3 routers. This is what's going to be used with the centralized snap functionality as well to provide redundancy for those nodes that are providing that. But even outside of that, for people that don't want to use the DVR functionality, this will provide HA for all of their, their L3 routing nodes as well. This work is also scheduled for Juno right now. The entry implementation is going to utilize, keep a live D for this right now. There is a blueprint file for this right now. This is also something that I think a lot of distributions are, are interested in, in getting upstream as well. So I'm, I'm hopeful that this work should land in Juno and, and leave some of the issues with the, with the networking node being a single point of failure for a lot of operators. So one other, one other note, one other interesting thing from an operator perspective is the work we have in Neutron going on around flavor frameworks. And a lot of this ties back to, to services to some extent, whether that's service plugins like LDAS or VPN or firewall or something like that. The idea with the flavor framework is this is a way for that, that we're going to allow operators to offer network services to their clients and their tenants, essentially. We're going to try to separate the driver functionality and configuration from the consumers of these services as well. And additionally, we'll allow multiple backends to function here as well. There, there's currently some discussions going on, on right now around the flavor framework. There's, there's a couple of different solutions that we're looking at trying to tie together to come up with a common one to, to have this implemented. But I think this is something that, that the operators are, are excited about. We, we had a meeting with a bunch of operators in, in San Antonio last week and they were, they were pretty excited about the flavor framework. And, and I think even, even the vendors have been pretty excited about this as well. It's really nice because it allows the operators to expose different functionality, different service level and tie it back to specific back-end driver implementations as well. So, so I think this is going to be a pretty exciting thing as well. I, I thought I would, I thought I would throw at least a slide up about NFV as well. There actually is a, an NFV sub team or project, which is not specifically under any sort of neutron umbrella because NFV and OpenStack encompasses more than neutron. There's also some things that's associated with NOVA as well. I just wanted to highlight that, that there are some people in neutron that are working with this NFV sub team as well on, on the different features that they want integrated in here. And obviously these would be things like service chaining, traffic steering, things like that. There are a lot of proposals around this right now. There's, there's in fact some sub teams that have been looking at service chaining and traffic steering for, for the last cycle. So it's hopeful that we can get some of this work merged upstream, but I suspect a lot of this may end up being a, a longer than Juno term type of thing. This, this would also include even simple things like VLAN trunking support for tenant networks as well, things like that. So a lot of the NFV work is, we'll see what lands in the Juno time frame. And I would expect that there'll be a larger push in the K time frame as well. So the next couple of slides, I wanted to highlight for Juno what new, what new plugins are, are either in the process of being merged or already merged and also what plugins are, are going to be removed from upstream. So right now in the Juno time frame, we've, in Juno one, we merged a Cisco A-Pick plugin and a free scale SDN, excuse me, a Cisco A-Pick mechanism driver and an L3 routing service plugin. And we also merged a free scale SDN ML2 mechanism driver as well. So those have merged. And if you go to the next slide, please, we, these are currently a list of, of the, of the existing drivers plugins and service, or excuse me, driver's mechanism drivers plugins or service plugins that are also proposed at this point. So we continue to have a, a fairly healthy ecosystem of, of both vendors and open source solutions proposing, mechanism drivers, plugins, service plugins and all of that upstream as well. You know, again, I mentioned before the, the third party CI and third party testing has been really integral to be able to handle this type of load with all of these new additions coming in and things like that. And we've, we've tried to focus on, on ensuring that as these plugins come in, we, you know, they're, they meet all of the different code standards that we have upstream and things like that. And it's, it's been really, that's been a good, good for us as well. And then I just wanted to highlight that in Juno, we're going to actually be removing the open V switch and Linux bridge plugins from the upstream source tree. This, this has been announced for a while. These have been deprecated for, for two releases since the modular L2 or ML2 plugin essentially takes over for both of these. That plugin still works with the existing OBS and Linux bridge agents at this point, but, but the general direction has been to deprecate these and move over to ML2. And I think as you saw in one of the other slides, there's, there's a healthy bit of ML2 mechanism drivers that are also being merged upstream. So, but these will definitely be going away in Juno. So that's all I had. So Margie, I'll, I'll pass it back to you. Okay. Great. Thank you. See any questions? I'll open up the line. Someone wants to ask a question. You are now unmuted. Um, I'm going to just ask, open it up with a question. It's kind of general. Uh, Kyle, I just wanted to know a little bit more about the flavor framework. Interesting. So are you hoping to standardize around a few different sets of frameworks with some suggested SLAs and things of that nature, or it would be kind of a, you know, a group of, of many. So I think the idea is in, in, in various deployments, you may have service plugins that offer different functionality. You may have load balancers. You may have multiple, if you use load balancer as an example, you may have a fancy hardware based load balancer from 810 or brocade or some vendor, and then you may have just HA proxy implementations that run as, as VM somewhere. So in that type of environment, you, you as the operator may want to set up flavors where tenants who want to utilize the hardware based load balancers may, maybe, maybe build more. And then if they're using the HA proxy based ones, they may be build less. It may be that the hardware based ones are offering some sort of advanced feature, which not everyone needs. And that's why, that's why they're, you know, they're going to be build more. But basically it's a way for the operators to, to more tightly control access to the different functionality for the, the different services that they're providing. Thank you. And then, David, I know that there was a lot of interest last round with dashboard with all the changes and extensibility and new look and feel to the design. Do you, do you see a lot of that input? I mentioned it in your presentation, but do you see a lot of that input coming from the personas group that kind of morphed into the horizon UX or, you know, from that side? And for those who don't know, there's a, there's a group of people who are looking at horizon within the Opusda community and kind of doing testing on the dashboard side. So I was just curious if that continues to grow or, or you're getting feedback from across the board. It's not necessarily just them growing. I mean, it's kind of an evolution of that group, I guess. Right. Yeah. So that's kind of a subgroup of the overall OpenStack UX effort, and we've been getting a lot of valuable input from, from both those groups. The personas group did most of the, or set up and ran most of the usability testing that we did. They also ran another study to try and determine the most common personas in OpenStack. And we're definitely there in the process of trying to, to working towards finalizing the output of that. And we're definitely looking to use that as input as we move forward, but a lot of the usability that we're addressing right now is not directly based on those personas. I think that's going to be down the road a little bit. So we're trying to let them finalize their work and then we'll, and then we'll pick that up. But that effort is definitely ongoing and, and very productive. And we're looking forward to being able to consume that. Okay, great. It's good to know. I peeked it on that group in five at a time, just curious. Okay, well, does anyone else have any questions? Quiet group? Okay. Well, this session will be on the Foundation's YouTube account in the next few days. If you do have any questions after the fact when the meeting is over, you'll receive an email and you can email us at the Foundation directly and then we can get back to David and Kyle as well. Or I think David and Kyle shared their information too, so you can contact them directly. David and Kyle, I know you're both very busy. Appreciate your time. And with that, I think then we'll, we'll conclude. Oh, thank you. Thank you. Thanks everyone. Have a great day. Bye.