Beyond the Horizon, part 1

If you are familiar with Openstack cloud platform, you have definitely seen OpenStack Dashboard for managemement of various resources and parameters of the cloud, but if you are a Django programmer, you will probably see Horizon framework features on which actual OpenStack dashboard is built upon. This blog post targets Django Developers, not much Openstack end-users.So what do we exactly mean by going beyon the OpenStack Dashboard? Someone can say that changing logo or add some panels or dashboards is topmost expectation for Openstack Dashboard tuning.

There is however another perspective where we can see Horizon as quite ultimate tool for creating impressive user interface for whatever we want/service. This blog post covers some advanced features of Horizon and our extensions and contributions to it.

What is the Horizon

By the official definition “Horizon is the canonical implementation of OpenStack’s Dashboard, which provides a web based user interface to OpenStack services including Nova, Swift, Keystone”. It’s a little misleading and there is a big difference between Horizon (Library) and OpenStack Dashboard. Horizon is a django framework, which provides tools for common patterns for data management like tables views, modal forms, or complex workflow definitions. Opestack Dashboard uses Horizon to implement graphic interface for all core services from OpenStack family. It contain support for all main openstack services, but many extensions are provied by vendors and newer or experimental services.

What is OpenStack Dashboard

Openstack Dashboard usage is actually API, data and workflow definitons of OpenStack services that use Horizon, but is straightforward example with specific points. Authentication is provided by keystone authentication backend only. OpenStack Dashboard has no own data model, utilises OpenStack python client libraries to access each services, in the core OpenStack horizon has support for following services:

  • keystone
  • nova
  • neutron
  • glance
  • cinder
  • heat
  • swift
  • ceilometer
  • trove

Thirt-party Horizon modules

Horizon has many extensions which are adopted by community, there many various extensions which live under main community group StackForge on Github https://github.com/stackforge. There are extensions for all services, but this post targets only Horizon plugins. The following table lists some of the most popular Horizon extensions.

NameVersionDescriptionLink
Merlin Framework for building UIs for OpenStack projects dealing with complex input data. project home
Sahara I, J, K Sahara aims to provide users with simple means to provision a Hadoop cluster by specifying several parameters like Hadoop version, cluster topology, nodes hardware details and a few more. project home
Mistral K Mistral Dashboard is an extension for OpenStack Dashboard that provides a UI for OpenStack’s workflows as a service. project home
Murano J, K Murano Dashboard is an extension for OpenStack Dashboard that provides a UI for Murano. With murano-dashboard, a user is able to easily manage and control an application catalog, running applications and created environments alongside with all other OpenStack resources. project home
Congress K Congress Dashboard is an extension for OpenStack Dashboard that provides a UI OpenStack’s policy as a service. project home
Trove I, J, K Trove Dashboard is an extension for OpenStack Dashboard that provides a UI for OpenStack’s database as a service. project home
Juniper Contrail G, H, I, J, K Adds support for Network IPAM, Network Policy to base Openstack Dashboard. Requires contrail neutronclient. project home
Solum Horizon plugin for Solum Purpose of this plugin is to add Solum capabilities to the openstack dashboard. This plugin requires a working openstack install including solum and horizon. project home

tcp-cloud Horizon modules

The following lists shows our dashboards and extensions which can make your life with Openstack a little more comfortable.

NameVersionDescriptionLink
API Mask I, J, K Plugin replace IP and protocol in EndpointsTable. Usefull if you have OpenStack API behind proxies. project home
Overrides I, J, K Simple Horizon plugin which solves plugin overrides issues. project home
Sensu Monitoring I, J, K Allows list events from multi Sensu APIs aka Uchiwa datacenters. Known Error Database as optional service provide store for your errors and workarounds. Monitoring, issues and solutions in one dashboard. project home
Heat Server Templates I, J This is a simple Horizon extension for support loading local Heat templates. project home – Not added yet.
Contrib I, J Library built on top of Django and Horizon(part of OpenStack Dashboard) for building modern web applications. project home – Not added yet.

 

Image 1: Billing plugin, allocation overview

 

 

Image 2: Billing plugin, resource usage overview

 

 

Image 3: Heat Server Side Templates plugin

 

 

More about horizon-contrib

Horizon is designed for API exposing application such as OpenStack, but what happens if we want Horizon to cooperate with other Django applications? At the beginning, nothing!

You have to rewrite the same components over and over again, for simple model table you must define a table, a view, urls and templates and for simple CRUD operations you have to write a view, form templates and url mapping. To fight this repetition you can use our Horizon-Contrib app which has implemented model based forms, views and workflows without any further prerequisitions!

Horizon-Contrib is a small horizon extension library which allows for most of Horizon components to work with regular Django models. This means if you install horizon-contrib into your standard Django project you have data tables with CRUD actions for each of your application models without any line of code. That’s not all, horizon-contrib provides other utilities for various repeatable tasks that every simple dashboard usually contains, like simple FilterAction actions.

Extending Horizon, the old way

We can simple disable or enable new dashboards with new cool features for managing any aspect of cloud or any other service with API. We can easily extends Horizon with new cool features.

Adding new panel into your Horizon, for example Juniper OpenContrail located at https://github.com/tcpcloud/contrail-horizon.

To add this network panel modifications we must install the app and have it in PYTHONPATH and we have to configure Horizon like this:

INSTALLED_APPS += ('contrail_openstack_dashboard',)

HORIZON_CONFIG['customization_module'] = 'contrail_openstack_dashboard.overrides'

Multiple customizations problem

What if you want add another panel which has some customizations? You have a problem! Yes you can simple do import overrides from another module or plugin, but with many plugins it has exponencialy complexity and maybe will be hard to manage dependecy and optional modules etc.

We use about ten plugins at any OpenStack installation and this approach introduced problem how to override multiple plugins at once. We have created a small utility which provide api for customizations exactly for this purpose.

  1. Install horizon overrides.
pip install horizon-overrides
  1. Add these lines into your local_settings.py. To enable our override models that collects and executes all other customisation modules in given order.
INSTALLED_APPS += ('horizon_overrides',)
HORIZON_CONFIG['customization_module'] = 'horizon_overrides.overrides'
  1. And finally configure overrides for desired installed.
INSTALLED_APPS = (
    "horizon_overrides",
    "horizon_telemetry",
    "horizon_monitoring",
    "horizon_billing",
)

OVERRIDES = (
    "horizon_telemetry.overrides",
    "horizon_monitoring",
    "horizon_billing.another_name_of_override_file",
)

This horizon plugin collects overrides from every installed applications by default. However if OVERRIDES configruation property is provided, it only include override for stated application.

Extending Horizon, the new way

Horizon has completely reworked possibilities for its extentensions since Kilo release. We introduce some aspects which were introduced or have changed. New pattern for extending Django applications was introduced in Horizon, because majority of contributors which create Horizon extensions are people who know a little about Django. For this reason there is a stable API which makes it possible to extend your OpenStack Dashboard without any further skills.

Obviously you can create your theme with company logo and some color variations or you can change layout or disable some parts from Dashboard. If you are company which wants integrate its awesome services to OpenStack Dashboard you must write a new Horizon plugin.

Branding

Most easiest part of extending Horizon is brainding which may contain new logo, color variations and other things. Since Juno release was changed CSS preprocessor from LESS to SCSS. For Horizon’s end-users this means that all their awesome themes for horizon is not compatibile with new release, but this is history and now we have all awesome functions from this framework. Dashboard theme was split to layout and color part with variables for easy customisation of components. See Github repository and check both branches at http://github.com/openstack/horizon/tree/stable/kilo/openstack_dashboard/static.

New custom module system

For more heavy features there is now a plugin system for easy enabling new modules in your Horizon instances. These modules may be located anywhere with descriptor in local directory of openstack_dashboard installation. Information from these files (one per module) are collected into main configuration settings. This is not ideal as it forces users to create symlinks or copy config files to this predefined location. We have improved this pattern in other application built on top of Horizon and our approach is driven by installed plugins. This means if you have something installed will be included.

Local enable file allows aggregation of configs for multiple applications. The following code shows one application enable file.

# The name of the panel to be added to HORIZON_CONFIG. Required.
PANEL = 'panel_name'
# The name of the dashboard the PANEL associated with. Required.
PANEL_DASHBOARD = 'dashboard_name'
# The name of the panel group the PANEL is associated with.
PANEL_GROUP = 'panel_group_name'

ADD_INSTALLED_APPS = ['app1', 'app2']

# Python panel class of the PANEL to be added.
ADD_PANEL = 'app1.panel.CustomPanel'

ADD_ANGULAR_MODULES = ['app1', 'app2']
ADD_JS_FILES = ['app1/js/custom-libs/ui-bootstrap-tpls-0.12.1.js',
                'app1/js/app1.init.js',
                'app1/js/app1.templates.js']

However this approach forces you to define panel or dashboard which is not the reason for the plugin as it may be theme or minor functional tweak of existing panels.

Enabling modules on fly

We must create an enable module and copy or symlink it to openstack dashboard’s enable folder to enable that module. There is a settings option to do that and it’s called overrides as we have shown earlier. But there’s yet another option to enable modules on fly. If you place following code code into __init__.py file in the module.

from horizon import conf
from openstack_dashboard import settings

conf.HORIZON_CONFIG['angular_modules'] = conf.HORIZON_CONFIG['angular_modules'] + ['rally-benchmark']
conf.HORIZON_CONFIG['js_files'] = conf.HORIZON_CONFIG['js_files'] + ['benchmark/js/report.js']

# reset compress settings for offline compressing
settings.COMPRESS_OFFLINE_CONTEXT['HORIZON_CONFIG'] = conf.HORIZON_CONFIG

Conclusion

This is the first of series of Horizon related blog posts. This first part showed the most common Horizon panels and extensions which we have provided to the community. The latter part described the old and new strategies to include module level configuration to global configuration mudule.

As we said, horizon is not OpenStack Dashboard, but is it most powerful framework in the Django world which provides awesome connection between backend-client world and also makes programmer’s life more comfortable. But is straightforward and only service API oriented which is little detriment for Django programmers. Installation the Horizon without OpenStack Dashboard is impossible and pypi package is out of date about 3 years and connect Horizon into Django Model is not helpful because you must repeat yourself without any visions of the future. But even though these disadvantages is Horizon the golden hammer for everyone who want create user-friendly interfaces, incredible easily and fast. After this hate we will show some solutions for explained problems and also next possibilities of horizon’s power in django world. The next Horizon series post will cover more about internal Data tables, Workflows and how to use them well.

Ales Komarek, Michael Kuty

Subscribe to Our Newsletter

Latest Tweets

Suggested Content

LIVE DEMO
Mirantis Application Platform with Spinnaker
WEBINAR
What's New in Kubernetes 1.10