The Horizon midcycle meetup was held in Hillsboro, Oregon from February 23-25, 2016. It was fantastic to meet up with everyone again (thanks Intel for hosting)! We had about a dozen Horizon contributors in attendance from 6 different companies. We covered a lot of ground in three days. Here’s an update on what we have in store for Mitaka.


Action Registry

We’ve created a batch action and item/row action registry. It provides a single point of entry for retrieving actions rather than having many custom services doing the same thing. Each of these registries is extensible (using none other than the extensibility service!), allowing third parties to add to the list.

We want to use the same pattern to handle labels and URLs, rather than have them scattered all over Horizon, we’d like to have one place to store and retrieve them.

Merged Patch –

Dynamic Themes

Horizon can be configured to run with multiple themes. Multiple themes are set in local_settings.html under the “AVAILABLE_THEMES“ variable in this format:

('default', 'Default', 'themes/default'),
('material', 'Material', 'themes/material'),

The themes are picked up by Horizon during the `collectstatic` process into the `static/themes` directory. From the Horizon dashboard, a user can then select which theme he/she wants to run and this is saved in a browser cookie. By default, Horizon is configured with two themes – ‘default’ and ‘material.’

Dynamic Theme blueprint –

Extensibility Service

Extensibility is a core component of the Horizon architecture because third-parties want to change and/or customize existing functionality to fit their requirements. Horizon has done a good job to accommodate this with its easy-to-use panel registration system. You can easily create a new dashboard or modify an existing one. However, it has been a pain point for users to customize at a finer level (without monkey patching or modifying source code).

Let’s take a look at this real life scenario: we have two teams within the same company that want to add a step to a workflow. How do we achieve this without modifying source code or having to resolve merge conflicts manually? With the new extensibility service! You can now extend the workflow to append/prepend/remove/replace steps. In the future, the extensibility service can be applied to table columns, actions, quotas, and form fields – you name it!

Merged Patch:
Liberty or Death: Horizon Dashboard Plugin Deep Dive (includes a demo to address the above use case) –

Better integration test coverage (Moar tests!).


We also have several prototypes in review.

Angular Directives

While building panels, tables, forms, workflows in Angular, we’ve started to find patterns and generate directives for those. Directives allow you to extend the basic HTML elements to do new things and create reusable components. You can take a look at what we currently have here.

For example, for creating tables in Angular, we’ve been writing similar HTML markup. For those who want to create a basic table, this can be quite tedious. The Angular table directive abstracts the underlying details, allows us to pass in the data and a column structure and wah lah, get a table back. Those who want complete control over their table can still write the HTML markup, but now we provide another option.


We want to make developers aware of the latest features we have. Since the Horizon framework is always evolving, we have to keep the documentation up to date.

How to Create, Package, Install a Plugin –

We currently are not generating the Javascript documentation from source code. Also we are not testing that we are following proper guidelines. This is being investigated.

Extending a workflow –
Translation support for plugins –

Dynamic Themes

We have a few items to make themeable, including checkboxes, select menus, and radio buttons.


A profiling tool to be used by Horizon developers to check performance before a commit is merged. It currently requires Ceilometer, but in the future would be able to work with different backends. Its capabilities will include such things as checking duration of fetching Django views, profiling actions requests, getting a drilldown of all actions taken during a timed session, getting activity traces, and providing visualizations.


Searchlight is essentially a search engine for OpenStack. This search was first implemented and released in the Kilo cycle for Glance. It has since expanded to Nova servers and Designate and in progress for Cinder, Neutron, Swift, and Heat. It indexes all the data from the APIs and provides “distributed, scalable, near real-time, faceted, multitenant-capable full-text” searches.

The powerful capabilities will be essential to Horizon going forward. For example, it may be the landing page for Horizon for you to quickly search for what’s important to you. In addition, you can quickly access that resource’s actions without having to navigate to the particular table to find the action. It may also allow users to assemble their own panels. For example, a user is interested in Heat and Images panels so he/she builds these as his/her default page and saves them so that in the future these will show up when she logs in.

Due to the complex nature of the searchlight integration into our current UI framework, we’re working through establishing patterns for our Angular tables and actions. Some action items include building a composable actions, label registration system, and table registration system.

Searchlight –
OpenStack Searchlight Presentation –


We are creating an Angular version of the Swift Panel which will overcome some of the usability issues encountered in the Django version.


More Angular dev
Pattern Library


Priorities for Mitaka:
Topics for Midcycle:
General Notes for Midcycle:

Happy Coding (and reviewing)!

Join The Discussion

Your email address will not be published. Required fields are marked *