-- 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.