-- What is the Openstack Dashboard? --

The OpenStack Dashboard is the upstream web UI for OpenStack. It's a Horizon application; Horizon is mostly python/django with a fair bit of Javascript. In the release we're currently running the js is strictly client-side but future versions seem to run some node.js on the server side as well.

Our deployment includes several custom panels (which are largely self-contained) as well as a number of customizations to the stock dashboard.

Because of strict API versioning, the Openstack Dashboard does not need to run the same version as the OpenStack projects that it talks to. Generally any version of the dashboard that post-dates the OpenStack versions is backwards-compatible. We're currently running the Mitaka dashboard with Liberty versions of the other Openstack Packages. We could potentially run the N or O dashboard, or even the development tip without incompatibilities.

-- How is Horizon deployed now? --

1) The upstream code is deployed via a Debian package along with its many, many dependencies. Those packages come from the Ubuntu cloud repo and are pinned to particular Openstack releases.

2) Puppet installs our various custom panels inside the debian-installed tree (which I do not regard as a hack).

3) Puppet installs an overrides.py file which monkey-patches some internal Dashboard features (this is kind of a hack but at least one explicitly implemented by upstream).

4) Puppet clobbers some upstream files with local, modified copies that live in the puppet repo but need to be tweaked for minor bug fixes and for various reasons can't be handled by overrides.py. (This is definitely a hack!)

-- How would we like to deploy it? --

We'd like to deploy Horizon using Scap3 and wheels, much like Ores and Striker:

1) We'll have our own fork of the dashboard repo 2) A script on a build machine will use pip to fetch all the appropriate python dependencies for our selected Dashboard version, and pack each dependency into a wheel. 3) These wheels are committed into a deployment repo. 4) The deployment repo is pulled onto Tin, and the whole mess (with all dependencies) is pushed out into a venv on the Apache server via scap3.

-- What would that get us? --

* We could deploy arbitrary source branches of the Dashboard, potentially running the upstream tip or at least picking up patches as soon as they're merged upstream.

* We could maintain an internal branch of the Dashboard code in gerrit and apply local fixes or custom UI changes, managing those diffs and changes with git rather than via puppet overlays and monkey patches.

* We could do this on Stretch! The Dashboard and many dependencies would be freed from reliance on the Ubuntu cloud repo (or Debian repos to be named later). Dependency chains would come directly from the python requirement files and be resolved by pip and other scripted tools.

* The Dashboard deployment would no longer be strangely mingled with the puppet repo.

* We'd have clear version reproducibility for the whole dependency tree

-- Why wouldn't we want to do this? --

* Because we'll be running code that was pulled down by pip rather than from a debian- or ubuntu-vetted .deb.

* Because change is work.