Alternative Interfaces for OpenStack

What might alternative user interfaces for OpenStack look like? If you’ve read my previous post on Composable OpenStack, you understand that there is more than one way to think about – and interact with – a cloud. Use cases – thus desired user interaction – vary even more than business models, and while Horizon’s OpenStack Dashboard admirably satisfies the Cloud Operator use case, there are many other use cases which it struggles to satisfy.

As a research exercise, I’ve collected and/or mocked user interfaces for the use cases I’ve outlined in my aforementioned blog post. These are intended to be illustrative, not proscriptive. Perhaps most importantly, these interfaces can – and should – be able to live side-by-side, with as little code duplication as possible.

Option 1: The multi-mega-cloud

I’m not certain anyone has ever tried to tackle the Mega-Ops user experience. Multiple clouds, dozens of global regions, thousands of pieces of hardware… it’s a daunting challenge to try to distill that into a single, usable, interface. I’ve taken a stab at it, however it’s probably far more useful to focus on specific users; A NOC’s security dashboard might be entirely separate from its capacity dashboard, and may even be managed in an entirely separate location.


Option 2: The single-cloud operator

This is the use case closest to Horizon’s OpenStack-Dashboard. Here, the customer knows they are interacting with a cloud – concepts such as instances, quotas, images, and network topologies are front and center, and both the cloud’s operator, and their customers, will find the concepts familiar and/or easy to grasp.


Option 3: Is there a cloud here somewhere?

I’ve taken a screenshot here of the signup page for, one of the keynote customers from the 2015 OpenStack Summit in Vancouver. Pantheon built their entire business on top of OpenStack and Containers, however this is entirely hidden from their customers; All they know is that they enter some parameters, ‘swipe’ their credit card, and have a wordpress blog ready to go.


Option 4: The Application Developer

This dashboard is designed for an application developer, someone who cares more about the components of their application, than about the underlying instances running these components. In fact, the developer implicitly trusts their cloud provider to configure these services in a way that will scale to meet their needs; After all, not every engineer can learn everything there is to know about every service in their application stack, as this breadth of knowledge comes at the cost of depth.

And yet, this is still a valid dashboard for OpenStack, especially its secondary services such as Trove and Sahara. In fact, this interface removes the source of computing power entirely; the resources could be provided via HyperVisors or via Containers, and the customer would never really know the difference.


Option 5: The Single-Service Deployer

The last use case is that of the single-service deployer, in which, for whatever reason, a single service such as Swift or Ironic are deployed entirely by themselves. Here, I’ve taken a screenshot of the Ironic Standalone UI, which attempts to meet that use case with no dependency on Horizon whatsoever.

Screen Shot 2016-04-06 at 2.25.37 PM

Horizon Usage Survey

Over the past few weeks, I’ve run a survey that attempts to discover how people use OpenStack’s Horizon (aka openstack-dashboard), and I’d like to publish some preliminary results. I’ll be soliciting responses during the Vancouver Summit next week, so if you haven’t participated yet, you still have time to do so. The link to do so is here:


In two weeks, the survey gathered 36 responses. Due to the small sample size and the non-random selection of participants, this data should not be considered statistically significant — Self-selected populations rarely are — however it does provide us with a window into how Horizon is used in the real world.

OpenStack Deployment Statistics

The following are charts that address the scale of our users’ OpenStack deployments.

Deployment Size

This is an indication of how many bare-metal instances comprise our user’s clouds.

OpenStack Version

What versions are currently deployed by our users. Note that some deploy multiple clouds.

Cloud Type

The type of cloud gives us an indication of what use cases our users encounter.

Horizon Deployment

These charts represent information about Horizon usage.

What is your UI?

Whether our users use Horizon, a custom-build UI, or both.

Install Tools

What tools do our users use to install and maintain horizon.

Host Operating System

The operating system on which Horizon is installed.

Horizon Customization

Information about the tools that are used to customize horizon, what parts of horizon are customized, and where Horizon falls short.

How did you customize?

There are many ways to customize horizon: Plugins, the Customization Module, creating your own Django Application with horizon as a dependency, or to just maintain your own source fork.

What was changed?

Which parts of Horizon were customized: Templates, Behaviors, Workflows, or more?

Maintained Source

In the case of a Django application, Custom UI, or a Horizon Fork, our users must maintain their own source repository.

What is the one key feature missing from horizon?

This was a free-form question, so I’ve taken the liberty to group the responses into different categories.

Usability and simplified experience

These responses address simplicity and usability in horizon.

  • Customer Facing features that improve and simplify the experience.
  • Masking Networks that cannot be attached to an instance during the instance boot wizard.
  • Simple image panel that only shows latest images, instead of all images.
  • Improved access and usability of horizon’s metrics visualization.
  • Use-friendly instance creation.
Hosted Cloud Features

These seem to be feature requests focused around hosting a cloud provider and selling it as a self-service cloud platform.

  • Self-service project management (Project Admin/Owner, etc).
  • Billing & Pricing integration.
New Features

These appear to be features

  • Approval Automation for Quotas, Tenants, and allocations.
  • Cloud Federation.
    (note: one respondent indicated that they fielded their own user interface because horizon could not talk to other clouds)
Extensibility Improvements
  • Panel Extensions are difficult to manage.
  • No uniform way to import horizon extensions, too many options.

For the sake of completeness, I’ve added features here that are not easily categorized.

  • Invincibility
  • Too many to List