 I'm going to present something about Horizon and it was announced as deep dive and customization. I will keep the customization stuff a bit shorter. We'll have a different session about Horizon and extending Horizon on Thursday. So what are we going to do? This is the agenda, something like an overview and so on, you could guess. Who am I? I'm a Horizon contributor since I think January 2013 and one of about 10 and I'm also contributing to Fedora, RDO and Red Hat OpenStack. And of course I'm using open source mostly only, exclusively. So Horizon, I was trying to describe what is Horizon if you're looking from the outside. It's a Whiskey application running in HTTP and if you're using a cloud installation, it's most probably the thing you're hitting if you're using it the first time. It's the graphical interface to interact with your cloud. But on the other side, if everything goes well, you're just using it once or even twice. First time to start an instance and second time to stop an instance, that's it. It's implemented in Python using the Django framework and it's been part of OpenStack since I'd say since ever. And I'm like many, many other Django applications, it's stateless and it doesn't use a database. If you're using or if you're using from upstream installation, it doesn't use a database at all. Everything we get is read from Keystone and Horizon doesn't store anything. So going a step deeper into Horizon, it's mostly separated into, I'd say, dashboards. Something like we are focusing on one side on projects, which is expressed by the project dashboard. You see options to handle instances, images, volumes, networks, if we are talking about your own small project. And lately we had additions about stacks databases and Sahara is our Hadoop service. So switching to admin features, Horizon is not about to set up your cloud or to configure your whole OpenStack installation. It's first meant to be the end user interface. Nevertheless, we have some admin features, for example, identity features, which was broken up lately into a third dashboard, but it makes sense to have it there. You could set quotas, flavors, you can get some statistics on the hypervisor board or, yeah, and also we have the ability to disable scheduling to specific hypervisors so Nova wouldn't spin off new instances on that specific hypervisor. But that's the only feature I currently know which could be considered as infrastructure administrative command. So features not included in Horizon for several reasons is you cannot set up your cloud infrastructure. You cannot configure by using a graphical interface like adding a new keystone, adding a new Nova host or whatever. You cannot deploy any nodes, you cannot configure storage, and we don't support vendor-specific additions right now. Of course, every rule has an extension. There's currently a router dashboard included in Horizon, which is meant to be a dashboard for a Cisco-specific addition. So if we are going a bit deeper, Horizon requires Django, of course, it's made of Django. Django is a quite cool framework, and it makes sense to have it, or it made sense to create Horizon on top of that. It's quite actively developed, still active-developed. We have seen a release cycle of about every nine months, and Horizon, well, it's a bit different from what we have in OpenStack. In OpenStack we have releases every six months. No, Django has more frequent release like every nine months, and as well a stable release, which was 1.4 until April this year, now it's 1.8. We as Horizon upstream currently don't support Django 1.8 yet. The previous release of Django is still supported, but it will go out of support when the next Django release will be out. So latest Horizon you can get is still running on Django 1.7, and 1.7 will be deprecated around Christmas this year. So Horizon also requires a Django application, which is used to collect and compress all static files sent to the end user, like JavaScript files are minimized and compressed and also concatenated to a single file, and this is just something, this application is taking care of it. And also it could be used to translate, for example, SCSS to CSS and so on. This is quite pluggable, so you don't need to worry about that. And if you're up to change anything in Horizon, you need to know. Static files in Django applications are directly copied into the source code, and Django has a command line option to collect all those static files and copy them to a separate place where it could be served by a web server. So if you typically install Horizon, it would be all those static files will be copied to user share, open stack, dashboard, slash static, or whatever. And the second step will be you need to compress them if you're using offline compression, which is something I would recommend, meaning your static files will be compressed once and then will be served by your web server and not every time when the web server thinks it needs to be refreshed. Over the Juneau development cycle, we removed all copied JavaScript files being considered as libraries to external packages. This is something I meant by Python static foo. Previously we had copies of JavaScript libraries directly in Horizon source code, which is, if you think about it, just briefly, just a bad idea. So we removed that and moved that outside. And if you're adding something to Horizon, I would propose to use the same like using these ecstatic stuff. It's just a wrapper and makes those libraries available inside your Django application or Horizon, but where it's currently copied in your or where it's installed, it doesn't matter, Django will take care of it and will include it. So you could use system JavaScript files. So next one. We need or we have authentication mechanism. It's named Django OpenStack Auth and it takes care of authenticating against Keystone. And it plugs into Horizon's, no, it plugs into Django's authentication mechanism. It creates a user on the fly when you log in. The user session is just dynamic. It retrieves a user token for you and takes care of refreshing that token. And also it's used for permission checks within Horizon. So finally we need all those Python clients like Python, Nova client and so on. Those clients are used for accessing the documented API via RESTful services. And basically all those clients are using the API the same way as the CLI tools would do. So if it doesn't work, if something doesn't work, first check the CLI tools if they work. If they don't work, it's obviously an infrastructure issue underneath Horizon. I bet you have seen this picture once or twice or whatever. It's actually the latest picture I got from upstream from the docs team, but it shows Havana. It doesn't matter, it just shows how services interact via RESTful services. And Horizon sits mostly between Internet and the rest of the stack. So what's new in Kilo? I was a bit astonished when I put all those slides together. We had 34 blueprints implemented, meaning new features, but if you're installing Kilo, you will mostly see just three changes at all. And this is a heat UI improvement. The data processing UI received visits, and we have metadata definitions admin your UI for Glance. But under the hood, we had many, many changes, and they are mostly connected with our re-implementation of everything in AngularJS. So, but this is disabled by default. If you want to use it or give it a try, you need to edit your config file, deactivate the old launch instance, and activate manually the new launch instance menu or visit. And then you could see more shiny features or more new shiny features in Horizon. And last but not least, we have a session about this on Thursday. If you're interested in that or interested in adding features made in AngularJS, please give that session a try. So if you're installing Horizon, you mostly have just two options to configure and anything else is just read from Keystone. So we need to know which Keystone to contact. And Horizon will reach out to the Keystone and will get all those options you need to know. The second one is allowed hosts. This is currently a security feature, maybe comparable to SELinux or so. I have seen many, many installations. They just said allowed hosts to ask a risk. Allowed hosts checks where your forms are originating from and will perform header checks on all forms. If they are coming from your Horizon host, if not, that's a bad sign. If you're allowing everything like in the first example, you don't check at all. Better you should directly insert your Horizon host or you could even wildcard a domain but don't insert that asterisk there. This was a big issue when we introduced a Django 1.5. Other options. In Kilo, we had a feature introduced to move the web route to something else other than slash. The reason for this is if you're installing your dashboard on the same host like you're using your Keystone, you could install your Keystone into your web server instead of running as a separate process and Horizon could reuse the same HTTPD. Both Horizon and Keystone are not using that many resources, so it makes absolutely sense to put them on the same host. Some stack API versions could be used to force the usage of specific API versions. In most cases you won't need that. If you're using your Horizon using SSL and you don't have bought SSL certificates, you would set SSL no verify that this would make your clients and also Horizon not to check your SSL certificates. If you don't disable this, mostly anything will explode. Nothing really works because SSL check will fail for reasons. You could even specify your own certificate to check. Then for logging reasons, no, logging is a huge dictionary which is very, very useful if you're hitting issues. If you're enabling debug, your log will basically explode because it's very, very, very verbose. Horizon config, it's something I currently skip. We have more options like Keystone-specific options or Glance-specific options. You could disable some features in Horizon. For example, if you have your identity set up for using LDAP and your LDAP is feeding your Keystone and your Horizon is authenticating against your Keystone, you are most probably unable to edit your password. You could disable changing your password in Horizon just by changing the Keystone value in the config file. Finally, it makes sense to add some caches. The first example will add a memcache to your Django application. Caches are used all over the application just to store some values. The second one is about the session. We had issues with the size of sessions over, I'd say, the last three or four releases. It's just the fact if you're having many, many services enabled, your cookie would get bigger and bigger. You could hit many, many strange issues if you're just using the predefined signed cookies session engine. My recommendation is to set up a database and use cached DB session engine, which can contain larger cookies than the signed cookies engine. Finally, our last thing about configuration is policy files. Horizon maintains an additional set of policy files other than the underlying services. That's good and bad. You could define, because it's separate, you could define a separate set of policies. For example, you could allow or disallow a user to upload images to Glance where it makes sense. If you're interested in policy and policy specification, you should visit that URL on our docs. So up to extending, we have, obviously, there are several ways to do so. So the first thing which could come in mind is fork the repository and change the source code directly. If you're thinking about that, think twice and think three times or even more, it's a bad idea. Honestly, don't do that. If you're doing that, you're not able to upgrade anymore. Better would be to add a customized panel or a dashboard, and in most cases, you don't even need that. If you're up to change the look and feel, we have several ways to do that. So separate templates from the logic, and a template is to be understood like an HTML file. And also, we have template text, which, for example, is more logic. And for example, our menu is made by a template tag. Just adding that specific keyword and the menu will appear. I talked about static files and styles, and this is something you should look up then. And I also mentioned Python ecstatic something. So if you're up to add new features, you would mostly add a new panel. Sometimes it makes sense to even to add a new dashboard. We have all those commands added directly in the tutorial, and I urge you to look that up. So I have just two examples. Left one is something we are shipping as Red Hat OpenStack Enterprise, and right one is how upstream looks like. And this is something you cannot do without just editing style files. You need to change templates as well. We had just a second. We had a feature in Kilo about adding a theming feature, and this is just pointing your installation up to a new location where CSS files are stored. And this is something you could use to add a different background or change the colors and so on. But you cannot change the way how menus are displayed or even menu order. You cannot change that by just using the theme feature. But there's a possibility to change or hide menus or dashboards just by adding a small config snippet to the local directory. And the example just shows how to remove the info panel from the admin dashboard. This is just one example. If you're adding a new dashboard, you could even change the order of your panels added to the dashboard. When you're going to change Horizon in some way, you mostly probably will hit some issues. And Horizon is hard to debug. So if you're getting a report about this or that doesn't work, first thing is to check does it work with Nova? If not, you're out of the game, it's not a Horizon issue. Then next option would be set debug to true and restart your web server. Remember the log file will be very, very verbose and it will basically explode. You could use your logging dictionary to cut that down. If you have the idea it might be a Nova issue, you could just enable or increase the verbosity of Nova logging in your Horizon log. And this most probably will help you in finding the issue more faster. If it's a Horizon issue and you're unable to fix it, please report a bug. Upstream on Launchpad. Bonus points for a rep-producer like a script or easy ways to rep-produce. Upstream we cannot do much about when I do this and that and that and that and sometimes this and that happens. What is sometimes and how do I rep-produce it? If you're sure it's a bug but you don't have a rep-producer yet, well, still that sometimes might help us to get a clue what happens. And if possible, add a stack trace to that bug. So if you're unsure about anything, go online on IRC to our IRC channel Horizon on Free Note. If you're sending an email to the devil list, tag with Horizon. As I mentioned, please report bugs. If you're adding a new feature to your private instance or to your private deployment, it makes sense to upstream that again or send that upstream. We have a defined process for this, the blueprint process. Even if you're thinking, is my little feature worth a blueprint or whatever? We have so many deployments out there and your feature, your implementation, still might help anyone else. And best, if your feature is upstream, you'll get it back in the next release. You don't need to backport it. Launchpad will be the main point of contact but not for questions. For questions we have ask.openstack.org and hopefully that even works. We have a weekly meeting at Ordinating Times Wednesday either on 12 or on 20 UTC and David is quite good in announcing directly to the mailing list. So I most probably have many things forgotten but I think that's for now. Any questions? I would just ask if you have any questions to please use the microphone for the sake of the recording. Thank you. I think that's working. There it goes. Do you know why the administrative control configuration stuff has been left out of Horizon? I figure that'd be something for like new stood up clouds that people don't really know what to do with yet. You're changing mostly infrastructure stuff and Horizon relies on that stuff. So for example, if you have the ability to change your keystone setting, if you're doing it wrong, you're immediately out of the game and you're unable to lock in again. So Horizon currently relies on having keystone, glance and nova installed. And if you don't have the three of all those, you're out of the game. The rest of the options are directly read from Keystone. So Horizon reaches out for Keystone and says, hey, dear Keystone, please give me your service catalog. I would still vote not to include those options in Horizon. But you know there's a plugin or an addition named Tascar and Tascar UI about configuring and deploying new installations. So you could use Tascar UI to install or deploy your new cloud environment in theory. Thank you. You're welcome. Hi. Do you know why the scheduler hints aren't supported in the Nova Launch instance? Scheduler hints. Nova scheduler. I would say no, it's not implemented. Do you know why? I have no idea why. But I have a mental list about features which should be enabled in new launch instance. But new launch instance is really new and shiny currently and it's marked as experimental for reasons. And I expect this to settle during the next cycle. Does the Horizon team struggle with tying the GUI to a filter scheduler which is an option? Is that part of the reason? Because they're not generic? No, mostly the issue is more like we are changing a lot of things in Horizon currently and we simply didn't have the time to implement more new features. How would you deal with that? Somebody doesn't use a filter scheduler, then would the hints still make sense in Horizon? Well, I'm not sure if it's really an end user feature. And finally, at least some cloud providers don't want their users to know what's implemented or how it looks like under the hood. Alright, thanks.