 Okay, so I want to get started right on time since I'm splitting the presentation time here with glance as well I am Gabriel Hurley. I am the ptl for horizon the open-stack dashboard project I did manage to spell my name and my Twitter handle up there correctly. That's always a good start So yeah, I want to talk a little bit about what we've done here what where we've been and where we're going every time I talk about horizon I like to start off with Just why horizon what is horizon? Why is it important? Because people have a lot of really mixed ideas about this and I think this is really fundamental to what horizon is about horizon is the open-stack dashboard There are a million things that that could be and when you come to these summits particularly you see Everybody else's dashboards and you go. Oh, that's so cool or so shiny that one's so new Oh, that one's so ugly, but it does all these other things that we'd like to do Why doesn't horizon do those things? The truth of it is that horizon has the unenviable, but extremely crucial task of being the middle ground We want to encompass the whole stack We want to make sure that all the core projects are represented We want to make sure that it is accessible to as broad an audience as possible and that you can do as many things with it as possible and that basically ends up limiting what we can do in terms of narrowing in on really nailing one particular use case in terms of being able to use the latest and greatest technology so on and so forth, but basically Why we have to do this is because we are the face of open stack when you see demos of open stack You see horizon when you see screenshots in press materials You see horizon when somebody who has never touched open stack before says hey Maybe this open stack thing is right for me. They spin up some kind of they follow one of the installation guides They use dev stack and they log into horizon so this is the first touch point for almost everyone who comes to open stack and We drive adoption. We are helping make sure the open stack spreads We are helping make sure that new projects are understood and are Usable by all the people who are around the world trying to figure out what the heck this open stack thing is We let them jump in get started and get going. So that's why horizon needs to be here And it's just a matter of how can we satisfy our own desire to create the coolest possible thing while still meeting those goals? So what happened in the last six months? This is a state of the union as it were talk about where we were when we started Folsom what we did getting to Grizzly And then after that we're going to talk about what we're going to do in Havana Grizzly There's your feature list image upload instance migration quantum routers load balancers network topology visualization VNIC ordering a flavor extra specs simplified floating IP management simplified security group rule editing image organization API access info on one place Better unauthorized API error handling icons and more. I don't need to go into all those features If you really want to know run the dashboard or go read the release notes. I do write really good release notes I promise But we did a lot of good things I want to just call it the large themes there, which is that we Did a huge amount with the quantum team to make quantum networking much more Featureful much more interesting one of the coolest things in there is the network topology visualization You can actually see all of your networks and all of your VMs if your instances in those Networks all laid out in a kind of graph and you can interact with them. It's awesome a great job to the quantum team for that We also did a lot with glance in terms of the image uploading and image organization and We did really I think more than anything what we did is we just made the user experience better We fixed a lot of the long-standing complaints of people having particular problems with one area or another and they're kind of tricky Edge cases where we need to really drill in and say what what is the best solution here? We have implemented this solution and that solution and the other solution all of them Just are dancing around the core issue So I think we took care of a lot of those issues and I think as we move forward people are going to Appreciate that a lot without realizing it. So it's the thankless work, but that's okay contributors gotta have the stats More than 20 companies about 50 contributors. We did we completed 22 blueprints More than 130 bugs and the total of about 200 change sets through through Garrett and into GitHub that's awesome It's every time every release horizon grows more companies more contributors more bugs more blueprints That's how it should be But more proud of I'm more proud of these stats and those stats and we added four new core developers from three different companies We grew by about 30 contributors Not that we didn't have about 50 contributors last time But people come and people go and we actually gained 30 new contributors this time Really importantly we started doing our weekly IRC meeting and we talk We all get together we talk right after the full open stack project update on IRC same channel and the open stack meeting channel I always forget what time it is in UTC, but you can find it on the open stack meetings wiki page. I Encourage anyone interested in Horizon to attend you can ask questions there You can find out what's going on there It's it's your opportunity to speak the mailing list is always there, but this is much more direct we added a ton of new documentation and Going back to that first point about the the new core developers from these different companies when we started the Folsom Cycle and in Essex and in Diablo before that the truth is my company Nebula Was really dominating the horizon project. It was almost a hundred percent argument All the core devs worked for us all the active core devs worked for us We brought in one or two people and they would work for a while people would contribute from the community And I don't want to marginalize anyone's contributions I mean we certainly had a lot, but we got accused frequently of Nebula just sort of running the dashboard That is no longer true Much to my dismay Nebula has put a lot less resources towards the dashboard I'm still very personally committed to it I wouldn't be PTL if I wasn't it's a labor of love and We are going to continue to build it, but the fact that the community has stepped up and responded is Fantastic, I couldn't be happier about that This is what opensports open source is supposed to be and this is the same story that we tell about open stack as a whole Oh, there was rack space and rack space is dominating everything and no now red hat and everyone else they've stepped up and rack space is 25% they're tiny little contributions now. So this is where we should be. Yeah, tiny you heard me I do also like to make the point that in Both Folsom and Grizzly and going forward into Havana Horizon is the only project in the core open stack that can actually claim full backwards compatibility with the previous release So I know a lot of people who actually run Grizzly Horizon against Folsom Everything else or Folsom Horizon against Essex everything else because it works all the features are there There may be minor discrepancies things that work more or less as intended But we actually do have compatibility, which is a big its source of pride for me And of course Grizzly is the best release of Horizon yet So what are we doing in the next six months Havana? We've talked about Havana all week. I should probably actually back that up for a second We talked about Havana all week and we had great sessions on Tuesday I really can't thank everyone enough for their participation. These are some of the best design summit sessions on horizon. We've had in the projects history And I want to highlight a couple of large themes in the next several slides The first problem that we really have to tackle is the problem of apis. We're now on to the Keystone v3 api We're on to the Glance v2 api We are soon soon Going to be dealing with a nova v3 api And until now we haven't actually had to nor has any other project had to support multiple versions of apis Which could exist in say a mixed cloud or when you're trying to deal with say federated clouds or a multi region installation So this is a big problem And I've been talking a lot to the other ptls and to the various people in the community while I was here about What's the best way we can support this? How do we do discovery on the api versions for the endpoints? How do we hook in little abstraction layers to switch between the various versions? And even more tricky is what to do about extension detection. So, uh, for example Excuse me, uh, quantum and nova Have huge numbers of extensions which expose different kinds of capabilities. Um, they may enable or disable features And until now we haven't been able to do anything about that in horizon at best We could add a setting and the cloud administrator could go in and say, okay Well, my cloud doesn't do x y or z, but this was this is not a sustainable solution, especially when um Projects are starting to publish actual api endpoints where you can list out. What are the capabilities of this service? um So that's going to be one of the first targets we hit in the Havana milestone because we have to We can't move forward with things like the keystone v3 api and just forget about v2 not an option So moving on to keystone As i've been talking a lot about v3 api Um, this is going to happen Everybody I have been getting asked every every time I talk to anyone about opensack When do we get the v3 api in horizon? It's happening very soon as soon as we solve that previous slide this happens. Um, that gets us domains Everybody's interested in domains. That's going to happen You'll be able to log in to your particular domain if you want to default domain if not You will be able to manage your domains if you are the keystone administrator You'll be able to manage things within your domain if you are a domain administrator things like that Which skipping down a couple items leads us to policy management All the core projects now are using the policy.json files using the policy engine to control Basically role-based access control. You assign a certain set of capabilities to a role and you can combine those roles however you like Horizon is going to be gaining Sort of a bi-directional support there on the one hand We're going to consume them and certainly tailoring the interface Based on the capabilities granted to that user is one of the things that the keystone v3 api gets us It exposes that read capability there Hopefully keystone in the Havana cycle will also add to that api a right capability So that you can as an administrator you can start managing your policy files throughout all your projects From horizon because right now what you have to do is you have to go in and manually edit that file on any server running A copy of nova a copy of keystone, etc And then restart them all That's not ideal So we'll be doing all those things groups roles, etc. The basically the missing pieces that people want out of keystone Um networking quantum as I said we did great things in uh in grizzly There's a lot more cool stuff we can do in Havana Quantum security groups IP management for administrators network quotas As I talked a little bit about the visualization interface. We're going to be doing more of that Probably even making that more of a first-class citizen and the more that I've been thinking about it in the couple days that we've been here at the summit The more I really want to see horizon I say see quantum become The first-class networking solution in horizon and an open stack I know there's been a lot of talk back and forth about what nova network is going to become how long it will stick around so on and so forth Do not take anything I say to mean that we will not be supporting nova network That's not going away as I said horizon's mission is to support all the core projects and all their configurations It's not a simple task, but we do it But for example, I was seeing the team from sisco doing their demo of uh, I've already forgotten the name It starts with a c What was that? Curvature. Yes, I was thinking convolution and my thoughts are convoluted. No, I've seen the curvature demo And the truth is that you can't get to really meaningful Stacks as heat would call them and we'll get to heat in a minute You can't get to meaningful network topologies. Those are types of things with nova network. It's just it's just not possible Um, and I think it's a much sounder strategy to move forward with all of the brilliant things that quantum enables us Craft a great interface around that and then to work backwards to the much simpler case of nova network where you really are only connecting Very very simple things So I really I want to work with everyone to bring quantum to the forefront there And see where we can go to make the interface that much more compelling around it as for heat Anyone who has seen what heat's been doing probably knows that they have actually been working on a horizon Panel for quite some time It basically works as far as I saw on on tuesday We will wrap that up and get that merged Very soon. Um, so heat support is coming as quickly as possible Also, we have talked about uh doing some of the visualization of stacks Taking that network topology view Turning that into a more reusable visualization and being able to Give you a couple of different vantage points Maybe perhaps being able to visualize the stack you're about to launch before you launch it Or being able to visualize the stacks that are running and see some information about what's happening Um, and how would you see that information? well, that means we get to integrate the cylinder and it took me a while to kind of think about this one because The obvious choice is well, what do you do with salamony throw some graphs in for admin? So okay, that's Not that interesting. Um, I think we can do better And I do still want to have those graphs, but I don't want to just throw like a metrics panel into the admin dashboard That would be lame. Um, I think one of the first things we can do is to bring um a lot more rich information to the Uh overview pages when you first log in so you can see a lot of information about your project You can see uh things like what are the Top consumers of resources in your project which instances are using the most cpu which disks have the most io on them What's using the most of your networking quota? Those types of information are so much more valuable than just saying. Oh, I'm using nine instances. Okay, who cares? So I want to bring that to the forefront We can have charts we can have graphs one of the larger themes of this release is going to be Unifying our kind of charting and graphing and visualization story We're going to use d3.js for any of you who know about javascript It's very standard library lots of people know it can do really cool things with it gives us a lot of latitude to go forward But so yeah, we'll have those types of things But my bigger story around salamony is I want to bring data everywhere I want any any place that you're looking in horizon can have meaningful context around it and salamony measures all of that And we need to be hooking that in so for example if you are looking at your list of instances and right now you get that very Static table. Well, what if you had? Little spark lines for your cpu usage next to each of those instances What if you had a little charts for for memory utilization? A little bar graph something like that you can actually learn something about what's going on with those instances Right then and then gives you much more meaningful Interactions with the entire cloud another great suggestion, which I hope said some point to come to pass is to build on What is coming with auto scaling in heat or wherever it ends up being? To take those triggering points those triggering metrics And tie that into something that could be displayed on your list of stacks and say okay Well on these stacks I care about uh cpu load and you know that this stack is really close to its trigger point And that something is going to happen there while this other one is completely unutilized But you can do this across any metrics that you actually care about it's a more dynamic system So there's a lot we can do there. I think it's an ongoing task to identify more places where we can bring value To the users based on that information We didn't really talk about nova explicitly at this summit, but I I always go through all the blueprints and all of the kind of recent Male conversations and such that I've had Before these these talks and for these summits and there are a couple themes that I see in nova that people really want One is the per project flavors, which is just a good idea Another really good one is in in grizzly nova added this idea of a kind of an instance action history So you can actually go in and see all the things that you did to this instance over the course of its Its life cycle, so that would be very useful And then there's a lot we can do about availability zones Both from an admin perspective and an end user perspective. We can do Some richer things there, especially once we get things like the capability detection in there So we know what we can actually do with nova And same deal with adding more information about hyper advisors if that's something that that particular cloud deployment The administrators find that valuable. We should be able to display that to them And the the hooks are there at this point, so we can we can do that in terms of How we get there particularly in terms of things like these complex visualizations and in terms of integrating Cilometer data all over the place We can't do this all Before the page loads. We can't be sitting there waiting for 10 different data sources API calls to come back on the server side. That's just it doesn't scale It's not the way it's not the right thing to do and we've gone back and forth on what to do about it for a couple releases now I can't say that the answers are that much better, but I think we're getting closer I think what we got Across the rest of the stack in grizzly has really brought us To a place where we can start accomplishing something meaningful here particularly Things like the fact that the rbc communication Library is being moved into oslo the common library means that we can much more easily Bring that into horizon and just hook into all of the other projects notification systems Much like Cilometer does and we can start consuming those Those messages and taking actions on them Other things like the fact that there's talk about this auto scaling ip API having sort of a web hook like function so that we can add in Just pass along a little url and say hey, why don't you ping horizon every time? You have a scaling trigger and then we can take action on that All of these hooks end up going into something we need to create which is a very simple kind of back end communication channel something that allows us to Grab these messages turn them into a format that works for us and then push them up to the To the front end asynchronously and to do that. We're going to use socket.io, which a lot of you I'm sure are aware of There are some Details which we need to do proof of concepts of as far as what the back end will look like to be able to do different kinds of Socket communication that could be web sockets socket.io also supports a lot of other things like ajax and xatarp polling So on and so forth. I don't want to get into the details of it because the details are what we have to work at But this is coming we can't avoid this anymore And that really is going to drive our ability to Build much richer interactions in the dashboard Aside from that What I want to make clear is that we are not going to lose the base functionality for people who Don't want real-time channels don't want extra ports open on their on their deployments for security reasons don't want Have restrictive browser policies can't use javascript can't use whatever else Um My commitment is to always maintain the core functionality of horizon for those people You may not get the best experience, but you will still always be able to use it. That's that's the distinction I think that's all I had and I'm out of time because glance is about to come up and talk about what they're doing I want to give a real quick opportunity for questions, but basically Let's do this and I'll see y'all in hong kong. It's going to be great So I'll take maybe two or three questions if you have them if you can step up the mic That's ideal otherwise shout it out real quick and I'll repeat it Billing is not something I want to see in horizon as a core function is something I'm Very happy to talk with anyone interested about as far as how to build something on horizon that you can Basically sell to your customers or whoever it is your enterprise that needs it But the problem of billing is one that cannot be solved generically in my opinion There's no right answer for billing So we want to give people the capabilities but not build it ourselves What do I view as the role of horizon for self-service portals? I think horizon Is a great fit for that. I think we can do a lot there. It's probably something we need to Basically allow people to enable or disable as they need But we can do a lot kind of behind the scenes under the hood to simplify the process for end users to get up and running in Environments where that's appropriate like like a free cloud. Yeah The question is for someone who is new to open stack or horizon What's the easiest way to find out about all these cool things that we're doing in networking? Dev stack is probably the easiest way if you want to actually try anything. Otherwise, yeah screenshots are Floating around the web. We should probably have a more coherent place for getting those up to date I know the marketing committee For the foundation often just grabs a bunch of them and does they do screencasts and things like that But I don't have a great answer for you One more if anybody's got one No, great. Thank you all. It's been excellent I don't know. Oh, I'm on. Okay. That's good. I wish to probably get started We only have about 15 minutes, but I probably won't take up the whole time. Anyway I should introduce myself. I'm mark washenberger or mark wash for short. Um, I'm the ptl for Open stack image or as I usually call it glance For the Havana cycle So this is the project update. So let's get started. Let's try to get started All right, excellent okay, so First let's talk about what happened in grizzly, which I'll pretend to be the most qualified person to talk about but I'm not really since I'm The ptl for the coming cycle and was not for the previous but There are definitely some things we got done in grizzly that I'd like to highlight In particular, we worked pretty hard on glance or I should say open stack image api version two And actually released version 2.1, which is just additional features on top of version two What I'd really like to highlight for people is that We now have image sharing supported in v2 And it's actually much better than it is in v1. I don't know if you know anything about this, but In v1 if you try to share an image or if you share an image with somebody It shows up in their list, right? So without them having any kind of interdiction at all. So Basically you could just constantly grief them if you wanted with some sort of Maybe I shouldn't even be telling everybody about this Anyway, we'll motivate we'll drive traction for v2 by releasing this We also added this is a more minor point But we added jason patch support for modifying entities We're kind of an early adopter with the jason patch scheme. So We had to play catch up during this during grizzly And then also during grizzly. We just had a lot of internal structural improvements Bug fixes and things like that That you know, you won't highlight any feature list but make life as a developer in glance much much better Should help us out in the long term There were a number of also small administrative improvements And if you really want to dig into the details there, you should look at the grizzly release notes so just added The required contribution slides. So unfortunately all these statistics are easily available So we actually had more change sets than horizon. So I'm proud of that However, if you take a look at the lines added and lines removed I'm sad to say that we did actually add code on the whole to glance at this time So it's always great when you can add features but cut down on the amount of code That'll be the goal for Havana. We'll see how we do You can see we had 64 developers, but we've had a pretty close knit community So it's been very nice working with them across 23 Employers and this is where you get those bugs that that we fixed. That's a lot of a lot of those lines Well, okay, that's good. How many did you start with? All right, okay so We we pretty much closed up our part of the Havana summit And I just wanted to give everybody an idea of the topics we've been discussing So they know sort of, you know, what we're thinking about what's sort of on the top of our minds We've had a session about trying to make end user direct use of glance better And if that doesn't make sense, I should make clear that a lot of large employers don't actually expose The open stack images api to their end users. They just sort of hide it behind nova Which has an endpoint that proxies to it So there are a number of features that we're looking at and trying to target so that we can make that just completely open Should help to separate out those services and maybe we can help delete some code in nova. That'd be great Um, we've been definitely thinking a lot about image transfers and how to make that faster It's it's definitely possible with glance acting as a middleman to sort of Shoot yourself in the foot in terms of networking performance. So we're looking at ways to make that just As fast as you can possibly make it There's been a lot of interest around image conversion a lot of controversy as well So we've been discussing that It's also been a proposal from rackspace in particular to Try to reach feature parity with ec2 on their copy image feature Which I don't know if you're familiar with essentially the idea is You have a different region say you have Someone has an image in one region and they want to copy it to another one so that they can have faster boot times in that region We've also had we've been beginning the discussion of how could glance support Rolling database migrations. This has been a big theme across All of open stack and glance is sort of a good guinea pig for this because it's not as complex as the other projects and It's actually just easier. Just the problems are a lot easier to solve there So we'll see how much of that we can get done in Havana So now i'm moving into the forward-looking like the truly forward-looking part of the presentation So everybody take everything I say with you know a little bit of extra Forbearance, I guess we'll say so the things we've been looking at To get done in Havana these basically correspond to launchpad blueprints that have been Approved or about to be approved. We've been looking at deprecating. How do we deprecate the glance registry? It's a helpful artifact to have for some deployments Where you have all these image workers that are doing large data streaming, but then just one Component that talks to the database and sort of you you have one only one place that needs to know about database credentials But it just makes it really slow. It means that the latency is just terrible So you you do a one request and it talks to keystone out here Then it talks to the registry which talks to keystone then talks to the database So you're basically getting five latencies when you really only want one or two But at the same time we want to support backwards compatible deployment sort of So don't worry about that if that sounds scary. We'll make sure that it works for you We've been looking at acls for image properties. This is something that we were looking at in grizzly, but didn't get around to The idea is to have Certain properties that a deployer says Basically a user can't change or Maybe a user can't even see those properties. So it's helpful for some sort of sort of secret accounting through metadata Um, there's been a lot of talk about quotas. Um, there's some more sessions about quotas in general Coming today, so we'll see how that pans out And as I mentioned, um, the copy image functionality. We're looking at we're looking at that I think we we're pretty much ready to move ahead with that One of the steps that we actually talked about in grizzly and feel like is really helpful for the process of image conversion and for Some of the steps that we need in order to copy images around is to have To introduce the idea of asynchronous workers in glance You know nova obviously already has this they have The compute worker that's just living off on your hypervisor doing all the work that it needs to do as Commands come in and we're looking at how can we add that and what's the right way to do that without burdening smaller deployments We've also talking about performance earlier. It seems like the goal right now is to just Um, when you store the image, you know, it's something like swift and glances just proxying it out Maybe we can look at just exposing that swift location directly or Wherever it's stored so that the end user can just not the end user But the client can just stream down from there rather than funneling and proxying everything through glance. That's sort of our performance So I don't have a see you in hong kong Slide, but I do hope to see people in hong kong. So that's all I have. Thank you. Does anyone have any questions?