Kilo Update: Horizon

Welcome to the PTL overview series, where we will highlight each of the projects and the upcoming features that will be in the next OpenStack release: Kilo. These updates are posted on the OpenStack Foundation YouTube channel, and each PTL is available for questions on IRC.

David Lyle is the PTL for Horizon, the dashboard component of OpenStack. In his PTL update webinar last week, he explained the high-level goal of Horizon and the updates and new features that are coming to Horizon in the Kilo cycle, many of which are geared at improving the UI for end users and operators.

Goals & Progress To Date

David started the webinar by surfacing the mission of Horizon:

“to provide an extensible, unified web based user interface for all integrated OpenStack services.”

With the big tent debate, the scope could creep out, but for now, this is an accurate representation of the mission for Horizon.

David noted that being extensible is especially important for Horizon because the OpenStack dashboard can’t deliver all of the functionality that an operator or end user would need. Every cloud runs extensions; Horizon should be able to support plug-ins for additional functionalities.

Before diving into the upcoming features and updates for the Kilo release, David gave a quick recap on Juno, covering the key updates:

Support for Sahara: this allows you to create clusters, create jobs to run on those clusters, and other data processing.
Better plug-in support: the team fleshed out primitive plug-in support from Icehouse. It now allows you to pull in static files, javascript, images, etc. and helps operators move away from the model in which they have to hack the code in order to extend it.
UX updates: the team was previously locked into some older versions of technology for styling in Javascript. This was updated in Juno and resulted in lots of styling and UX improvements.
metadata: the team is providing further enhancements.

Looking Ahead to Kilo

Support for Ironic

Horizon will support Ironic in the Kilo release cycle for both end users and operators. End users will be able to set up a bare metal instance and operators can specify new nodes and bring them in and allocate them.

AngularJS

One of the main areas of focus for Horizon has been around better user experience. Horizon has been moving towards AngularJS as a client-side architecture in order to provide better, faster feedback to users, decrease the amount of data loading on each request, and push more of the UI onto the client side.

For the Kilo release, the team is working on a reference implementation to dictate how AngularJS will be implemented in Horizon.

Improved Table Experience

Currently, filtering and pagination within Horizon are inconsistent. For Kilo, the table experience will be improved by much of it to the client side, caching more data on the client and providing pagination and filtering in the Horizon code instead of relying on the APIs to do it.

David hopes this results in a more consistent user experience, and takes the guesswork out of understanding the paradigm on each page.

Wizard

There is a wizard in Horizon currently, but it’s primitive and it has remained largely stagnant through Havana and Icehouse. David said he plans to refocus on that in this release because it’s one of the biggest usability issues Horizon faces — the launch instance workflow is confusing and requires a lot of upfront knowledge.

The Horizon team has been working with the OpenStack UX team to design a better workflow that will be implemented on the client side. The team will use the network wizard as well to make sure they have an extensible format and an extensible widget.

Refine plugin support

It’s important that Horizon has a clean plug-in mechanism that doesn’t involve editing horizon source code.

Right now it requires a user to add files into the directory where Horizon gets deployed; this isn’t optimal because it causes problems when a user wants to update a package. The Kilo version of Horizon will have refined plug-in support that allows users to point to where the plug-in mechanism is and provide better Angular support.

Better theming

One concern that operators have is that they don’t want to ship Horizon with the same UI as everyone else, especially if they’re putting it in front of customers. David said there’s a need to be able to theme it better without having to hack the code.

The team plans to continue development and provide an improved theming mechanism that’s easy to work with.

Federation and SSO (Single Sign On)

Many corporations that use Openstack already have an authentication backend where users are set up. They don’t want to have to duplicate their work by pulling all of that into Keystone. For Kilo, the team is working on providing a mechanism for a federated login and single sign on. Therefore, if you’re authenticated into your corporate auth system, when you come to Horizon, you won’t have to do it again.

The Horizon team is working with the Keystone team to provide federated authentication.

Multi-domain identity operations

Horizon currently supports multiple domains to a degree, but David said that the project needs a richer set of roles other than admin and member to do operations, and they need domain admin.

Horizon can’t support that currently because it doesn’t interact with Keystone the right way. The goal is to add in the support for the Kilo release.

Gating with integration test suite

The Horizon team has been pushing on this for several release cycles. Horizon has one integration test that runs in Tempest, but they’ve been working on getting an full integration test suite set up.

David said operators should be able to run all of the gating jobs by the end of Kilo.

Get involved

To get involved, get in touch with David Lyle or join the weekly Horizon team meetings. Date and time can be found on the OpenStack Meetings page.