 Let's go ahead and get started. Good morning. Today we're going to be talking about extending the pane of glass. And basically by that, we mean extending horizon within OpenStack. Before we get started, let me just say, this is a group of folks that I've been working with for the last several months. And they made everything that I'm going to show you today possible. So just a quick blurb about them. George on the left, Randy, our manager, Arpitasati, myself, and Jeff Kramer. This is a team that I've been working with for some time. I'm really proud of the hard work and effort of these guys. I've just had the opportunity to be here and present today. A little bit about me, I've been doing. I graduated from Furman University a very long time ago. And I've been doing software development for about 20 plus years. It's been a lot of years as a Ruby developer before getting into Python. And basically I've been working with HP since 2012 now. I've recently been working on the ALS team, which is within the HP Helium product line. It's specific to Cloud Foundry. Basically, standing up Cloud Foundry clusters within OpenStack. So a few caveats and promises that you either, I'm assuming you either know something about Django or can get up to speed pretty quickly on Django. We're not going to cover a lot of that today. And really, you'll see that the plugin mechanism we're going to talk about today has been around for a while. But we're really not going to talk about best practices in the sense that we, this is the direct result of the effort that we put forth in building the ALS panels or app within Horizon. So with that said, there's a lot of progress that we've made in a short period of time. And these slides and the sample app that I'm going to provide are going to be available at the end. So don't spend a lot of time trying to capture every bit of this. So today we're going to talk about what it means to extend the paint and glass. What does it mean to extend Horizon? We're going to talk about about three or different approaches, how you might want to do that. I'm going to go into some detail on the approach that I'm recommending. A little bit of homework at the end, things that you might want to go off and investigate as a result of going through and seeing this today. So this is base Horizon. This is actually DevStack Horizon and this is the user interface for OpenStack. If you look, there's something a tad different about this screenshot versus this one. You notice basically what we've done with the second one is we've actually incorporated WordPress and extended Horizon to include an interface to be able to talk to WordPress. Let me show you that to give you a sense of. So here's DevStack, here's WordPress. Here is a list of posts on our WordPress blog. And just to show you that this is not smoke and mirrors, this is the actual WordPress site we've got running in NHP Cloud today. So what I'm going to do within Horizon is I'm going to create a post and I'm going to say, until I've done this a few times, practicing. So if we do that and we say create, it's going to go off and create. You're going to see a green pop up to the right. If I go over to the actual site running in NHP Cloud, it's going to show that post in real time. So I come back here, I can delete that post and it's gone. And I'm going to refresh that again and it's gone here. So no smoke and mirrors, this is actually working. This is the code that's available on the GitHub site and you'll get a copy of this if you want to pull it down and play with it. So pretty cool stuff. So basically here's what we're looking at. Here's the overall diagram of what we're looking at. And that is, you've got a browser, you're hitting Horizon. Horizon typically, compute, networking, etc. We have added our own Django app into Horizon for talking to WordPress. And it basically is using XMLRPC over standard connection over to the WordPress site and it's pushing and deleting and that sort of thing directly via the standard WordPress API. So when you look at this, really what you need to be thinking about is, what does WordPress represent? It represents for you an application that you might want to pull in and use within Horizon. It can be, there are some good candidates for extending Horizon. And that would be things like line of business apps. So if you have a trouble ticket app, if you've got Salesforce.com, a CRM app, anything with an API that you can hit and do things with your app, that's a good candidate. If you want to customize aspects of an OpenStack module, if you want to, I don't know why you would, but if you wanted to disable the networks section for Inside of Horizon. Or you wanted to, for example, your corporate standard is such that up in the top right corner, currently inside of Horizon, it says settings to get at your user's settings. If you wanted that to be something like user profile instead of settings. This is a really easy thing to just tweak. If you want to do like we did, and that was build an entire management UI for CloudFoundry clusters or for other things in your organization, that's what we used it for. So if you want to extend it, it's a great target for that. If you want to, believe it or not, there are some folks have actually seen, I'm going to show you a couple of examples and bit. If you want to turn off all the Horizon modules and you actually want to use the Horizon Chrome, the Horizon UI. You can actually do that. Let me show you a couple of real world examples. This is our ALS clusters in the HP Healing Development Platform. This is our management UI that's running right within Horizon that allows you to manage your CloudFoundry clusters. And so if you want to, for example, if you want to create a new one, you click the create button in the top right corner and you're presented with this, you're going to basically specify some, the name of the cluster and some other information about the cluster itself and what you want to do there. You're going to pick what network you want to sit on. You can pick services that run within the CloudFoundry cluster and it'll build those into it. And you can, if you want to reference either a MySQL instance that's running within CloudFoundry or you want to reference a Trove, a DBAZ instance or instances, you can basically make the connection there so that when your cluster comes up, it's able to talk to those. This is another app that I recently became aware of within HP. It's called Sakura and it's a way that some of our groups internally manage racks inside of data centers. And they've basically are utilizing this. Each one of these actually represents a data center rack, better look at it. Rack to the right and you can actually drill down into it and get everything from the NIC to any of the other information about the blade server that's sitting in the rack itself. And they're actively using that to manage several of our data centers currently. Why would you want to extend Horizon? Obviously, from what I've been talking about so far, just for simplicity, consolidation, if you want one place, you want to avoid context switching, ease of use for your folks. It's a good place, it's a good thing to do. If you want to provide a control access in a standard way, in kind of a granular way across not only open stack but across your application, it's a way that you can do that. If you want to standardize on the horizon user interface, you like it. That is one reason why you might want to do this. All of this is talking about basically pushing development higher up the stack, reducing development time, reducing the amount of code that you have to write. And there's an opportunity there to take advantage of Horizon Django extensions, that sort of thing that are available within Horizon. If you don't have kids, you probably don't know who this guy is. But I've got three at this point, and so I know him all too well. But he kind of represents some of your engineering, maybe your support folks. They really like helping others. They have a boatload of tickets that they work every day. But they struggle to have time to breathe, eat a cookie, etc., in the afternoon. In all seriousness, this is what we do in HP Cloud. We actually have our cloud support ticketing app built right into Horizon. So this is another good example of where we're eating our own dog food. We're actually doing this within public cloud at this point. So let's talk about the three approaches. Let's get to the heart of the matter. There's really three ways to alter Horizon. There may be more. In our experience with the work that we've been doing, there were three ways that we considered. You can hack Horizon, you can override it, you can extend it. So let's briefly talk about the first two, we'll get into the guts of it with option three. You can basically hack on Horizon directly within the project. What I mean by that is you can clone it into a folder, you can jump in with your favorite editor and you can start hacking away and making it do what you want it to do for your purposes. And believe it or not, if you haven't done this, if you Google for customizing Horizon, there are gobs and gobs and gobs of stuff. It'll come up as examples of how you can do just that. But basically, it's a quick way to reach your goal, but you're going to pay the price down the road. And it's generally a bad idea. You can override Horizon. And what I mean by that is that you can create an individual Django app with a few small bits of code in it and you can override. And what I mean by override, for example, is if you just want to turn off a panel, you can drop this code snippet or one very much like it where you basically grab a handle to a dashboard. You get the instances panel and you turn off, I don't know why you'd ever want to turn off the instances panel, but that is the sort of thing that you can do. You can turn off a panel if you want to. If you want to tweak the UI, as I was saying earlier, for settings to user options, the second code snippet's going to show you just three lines of code, you can make that happen. That's a piece of cake. So for really super simple stuff, you can do this. It basically involves an overrides.py file sitting into a project with one or two of these old panels dropped in and you're good to go. This is the initial approach our team used and we quickly kind of ran into some issues with doing that and realized that that really wasn't the right way to go about doing it and so we stepped away. We're going to talk about the most important one and that is extending it and this is what I'm going to spend the bulk of my time this morning talking about. You basically extend it via a plugin approach that was introduced, David could probably speak more specifically to it, but it was introduced around the Diablo or Essex timeframe and it really has matured in the recent Icehouse release and it basically embodies really, really good software engineering principles. It allows you to loosely couple your custom app from the rest of Horizon. It means that upgrades are really, really simple and there are several ways that you can hook in and that's what we're going to talk about. One thing I will say, just a comment on syntax and on verbiage, if you notice within Horizon I'm going to talk about three things. I'm going to talk about dashboards, panels and panel groups. Along the left side you see the project dashboard top arrow in the bottom, there's identity. Those are your top level groupings. Within that you have a series of panel groups and panel groups would be things like compute, network, word prefs and then panels, overview instances, underneath compute you're going to see those. So basically what you're seeing in the middle of the page here is when you drill in and you've clicked on overview, that's the project dashboard, it's the compute panel group and the overview panel. So you can control and customize at about three different levels. I'm not going to go into a great bit of detail here. There's actually a link on the bottom of this slide that you can reference later. I just raise it, show it to you to show there's a bunch of ways in which you can extend different ways in which you can extend Horizon and these are some of the options you can take advantage of. This is more of a reference slide for later on. I will just say though that they are grouped typically into dashboards, panel groups and panels and then there are some general options that you can set over in a general sense over and above all of those. And let me just show you a couple of examples. We didn't choose to do this in the demo that I showed today but if you wanted to create a WordPress dashboard, the highest level item on that UI, you would simply define a dashboard here and enable it. If you want to create a panel group, it's as simple as having a particular panel group file in your project and you basically define the panel group, give it a name and say what dashboard it's going to be a part of. If you want to create a panel, you're going to define your panel, say what panel group it's a part of and what dashboard it's a part of. And your ad panel, the ad panel configuration setting actually references the Python, fully qualified Python or Django name for that particular object. So details of what we're actually doing, this is the nitty gritty, there's only three steps. And step one is really crucial and that is setting up your development environment properly and you'll see what I mean by loose coupling when I said, made that comment earlier. You basically need first a DevStack or an OpenStack instance and that's represented bottom left and on that what you need is an accessible IP address, you either need it in your local environment or you need it out somewhere in a publicly accessible IP address. But you have to be careful, if you go to the public IP address route, you've got to make sure that your standard OpenStack ports are open on that address or it's just flat not going to work. Secondly, you need a local horizon project to kind of drive, this is where your web server's going to run out of and you need that local and you also need your custom app. So that's what I meant earlier about this decoupling between your app and horizon. Your custom apps represented in the bottom right. All your code changes are going to take place there so you never actually touch horizon. So this is your development environment setup. Secondly, what you need to do is the custom app that you develop, you need to actually simulink it into horizon and it's a little hard to read but within horizon typically what you're going to be able to do is you need it accessible somewhere on your Python path assuming you run horizon in the context of a virtual environment, most people these days developing its horizon do. The cleanest way to do that is to install your custom app into that environment. So horizon here, down in Python 2.7, site packages, here's our WordPress app right here inside there. So that way horizon can get access to all of the pieces and parts of your custom app. And third, you're going to want to simulink a couple of things into that horizon app as well. One is your panels, remember earlier we talked about how we define those panels. You can actually define those panels in, I've defined them in these two files right here, ad-wp-panel-group and ad-wp-panel. And then if you have any local settings specific to what you're trying to do in development mode you're going to drop those into local settings.py file. I'll talk about that in just a second and clarify that. But this is inside of our custom WordPress app or Django app sitting inside our custom Django app. And where you're going to simulink those two is over inside the horizon project. You're going to simulink those into either the local or the local enabled folder underneath OpenStack dashboard. It's going to be your panels go under local enabled and your local settings are going to go under the local folder. So that's really, those are the three steps. Are you tired of simulinking yet? Well as it actually is a matter of running through this demo with a couple of guys that actually are more familiar with what's coming down the pike in terms of upstream, this is going to get even better. I mean to me it actually is not very painful at all to work in this way but it's actually in the very near future is going to get even better. A quick peek at local settings just to give you an idea this is how your app actually connects to OpenStack, your DevStack instance. Inside that local settings.py file you point to your OpenStack host, you set debug to true which if you're familiar with doing horizon development you want that in case something fails, you want a stack trace, you want to be able to see what's going on. And third I just am in the habit of setting my session time out to be larger than like I think the default is like 20 minutes and I'm constantly having to log back in so I just personally like that setting. Over in horizon what happens is if you do this and you sim link it over, when you fire up horizon into the web server, one of the last things in the settings.py file it does is it actually looks for a local settings file. So as long as you sim link that over he knows exactly where to go to hit Open, or DevStack and do what it needs to do. So I just, that's already there, take advantage of that. A bit of advice about the app structure. So your custom app, what I would suggest that you do and I believe this is a Django convention is create a folder and then create your app inside a sub folder of that. In this case WP is our sub folder inside the main folder and of course everything that we're sim linking over we've dropped into that bootstrap folder. I just like that because it keeps all of that in one place and I know I can go to that one place to make any changes I need to make as far as that goes. And one more comment about naming. One of the questions I had early on and it's not really, I haven't seen it addressed online in hardly any places but the numeric naming underscore 80 underscore zero underscore one, there's not a lot of significance to that other than it helps to order, it's used for ordering in what order are things going to get loaded in horizon. So other than ordering there's no real significance to those numbers. So just to recap for everything on one slide, you're gonna basically sim link your custom app over into horizon, any custom app settings that you have in the local settings.py file and then some link your panel groups and panels over into the dashboard. So as we're kind of coming to a close I'll say a couple of things that you can take and this is kind of homework for a takeaway and that is this is kind of a picture of what we're currently doing in Helion with respect to ALS or Cloud Foundry. This represents horizon obviously and this is our ALS app or panels that exist within horizon. We basically initiate cluster creation. I showed you the screenshots earlier about how you can create a cluster. In essence what we're doing here is once you say submit and go it actually spins up what we call a constructor an instance or a VM and that guy is responsible he's got all the knowledge to actually build a Cloud Foundry cluster and his only reason for being is to build that Cloud Foundry cluster. So we spin up that constructor VM he creates all the instances that based on the things that we pick in those dialog boxes and he creates those and once he finishes he just goes away. So he's the only reason for, we actually have a destructor VM as well but that's really in essence how we're orchestrating this process. There's tons of different ways that you can orchestrate. We found it very useful to be able to do all this right within horizon. The other comment I would make along the same lines is that there's a service within there's a metadata service that's successful in Nova it's a key value store and we actually take advantage of that in terms of communicating with the constructor. So as a constructor spins up and starts doing its thing in terms of creating the Cloud Foundry cluster we are actually setting, we actually store messages inside metadata on the constructor VM and we have actually what's known as a core node within Cloud Foundry that gets spun up and he does the same thing he stores messages there as well and what we do inside the horizon UI is we have code that actually goes out and pulls that metadata out and shows the status of what's going on as that guy is processing through and creating that constructor. If there are any problems or issues that come about it's reflected back. It's an easy way for us to get access to that information and it shows up back in horizon. So it's a nice communications medium. I can recommend it as one option in terms of status of your process as you go through things. The standard packaging distribution culprits, you know, salt, puppet chef, Ansible, normal stuff. The other thing that I would make a comment to and this is probably only for folks that are fairly new to working with horizon is if you don't have a way to debug Ajax app you really, whether that's Firefox and Firebug or whether that's Google Chrome and some of the tooling that's available there I can highly recommend that because there's gonna be all sorts of things that are gonna happen that you're not gonna have any idea of how to go about fixing those if you don't have that. So basically in summary, we did this in about four months. So in summary, I would say don't be intimidated by it. Basically establish a proper development environment. Keep those changes in your own app as opposed to inside horizon. It's just gonna make your life a whole lot better down the road. Obviously the plugin approach to us makes the most sense and just take advantage of the horizon and Django idioms that you come across. So thanks for that. I've mentioned my cat Wilson in the commentary so there's Wilson. But there's the contact information for me. I'm pretty sure that the GitHub repo is live at this point HP Cloud opens up Paris extending horizon. That's probably the most important link because if you can get to that you can get to everything. And here's my contact information if you're interested. And with that I will entertain questions. Yes, that's all right. We did not, if you look in the project that you can see there and I didn't do that in this demo but there are in fact places for CSS and JavaScript and that sort of thing. You have full access to call bootstrap from within your app. And I believe you could also get away with dropping reference bootstrap within those style sheets. So I think you can do that. We did it very little. We reused most of the styles that already existed in Horizon in our project. So, right. Yes. Well, I would say that with a caveat and that is that I'm by no means an expert on extensibility within Horizon. My experience with Horizon is about six months total. So I'm still learning about some of the extensibility approaches as far as especially with respect to style sheets. And I know that we have some sessions in the design summit around extensibility. So that actually might be useful to you if you're gonna be here for the rest of the week. Which I'll be here all week if anybody wants to chatter. I can certainly go into detail about what we've done and how we've done it. I'll be glad to answer any other questions during the week. Yeah. You know, I don't know. David, does that, that's not really an issue in this context, is it? The only thing I would say is probably I don't know that I would embed that sort of qualification in a custom app necessarily. I don't think that's necessarily the place for that. I would somehow flip that switch somehow externally and maybe check it from within your app to see. Maybe a group or a, yeah. Anyone else? Thanks for your time.