Hi all,

The last few months working on stx-horizon have given me a broad understanding of the customizations, new dependencies, additions and removals of LOCs that WRS have added on top of Horizon. For simplicity, let’s imagine stx-horizon as a superset of horizon that makes stx-specific functionality a reality. The downside of having and maintaining a custom “superset” of horizon is that catching up with upstream is expensive, painful and time-consuming that requires a having solid understanding of this project. In an attempt to alleviate the tedious, rebase work after every upstream release, a pluggable python package that would carry stx-specific functionality was the most sound option and architecture to adopt.

Horizon supports “plugins”, the recommended way to extend and add to the functionality that already exists and, after removing more than 25,000 lines of code from stx-horizon, the stx-gui horizon was born.

*the stx-horizon superset of horizon is smaller now*

What does the plugin do?

Stx-gui isolates new panels (System Inventory, Fault Management, Server Groups, etc), API wrappers for clients (cgtsclient, cgcs_patch, sysinv, etc) and many other utility functions that are specific to the StarlingX project. This architecture helps us to:

1. Significantly improve the way we deal with technical debt: rebases will be easier as more LOCs are moved from stx-horizon to stx-gui, until we end up using the upstream version of horizon ☺
2. Follow a community well-known architecture for extending horizon: “want to add custom functionality to horizon? Write a plugin”… that’s what you’d hear from the community

Another side-benefits from doing this splitting

1. Detected additions that can make horizon upstream better: this process threw light on the upstreaming work that I do in parallel.
2. Detected dead code: some files are still holding portions of code that are never executed
3. Found and documented hard dependencies that must be defined somewhere (requirements.txt)
4. An x-ray for understanding what the development documentation would look like
5. Understanding the dimension of the customizations made by WRS: horizon acts as a proxy between operators/users and API endpoints through python-clients. Future modifications to python-clients and APIs will certainly affect the way Horizon talks to them.

What does NOT the plugin do?

• It does not remove all of the customizations made to the internals of Horizon, that includes:
  • Any modification done to existing panels (built in panels like Instances, Containers, etc)
  • The horizon Framework (the way tables are rendered or respond to user actions)
  • Fixes to JS files, etc.
• Tests
• Tabs added to Horizon Panels: Network->Routers->Port Forwarding is an example
• It does not specify what dependencies it needs (but they are documented)

How do I use it?

The steps below are ONLY for development and assuming you’re developing outside of the VM running StarlingX.

1. Git clone stx-horizon and switch to branch post-stx-gui-cleanup, you can find the branch on my github profile or check the PR.
2. cd stx-horizon and create a virtualenv with py27 in it.
3. Install Horizon dependencies:pip install -r requirements.txt
4. Git clone stx-gui in a different directory outside of stx-horizon
5. cd stx-gui and using the same virtualenvironment for stx-horizon, run python setup.py install. This will create a packaged version of the plugin that is accessible by stx-horizon’s venv.
6. Install all stx-gui dependencies
7. Copy enable files inside of stx-gui/starlingx_dashboard/enabled/ to stx-horizon/openstack_dashboard/local/enabled/
8. Finally, inside of stx-horizon, run the horizon dev server with “python manage.py runserver”

The installation can be simplified and automated when building an ISO. I’m not familiar with the process but I can guide by explaining what steps must be followed and in what order. It basically involves moving to the right branches, cloning stx-gui, creating a package and copying files to one directory.

Please read the extensive documentation I’ve put on this etherpad for more instructions for better format.

What’s next?

There will be a number of things to keep in mind from now on, answering some questions can help to understand if a change goes to stx-horizon or stx-gui. Also, the long work to make stx-gui work with Upstream Horizon is still pending, but fairly documented thanks to the splitting process. The developer experience is important too, how can we make working with stx-gui an inviting place for others? Py3 compatibility and many other things that are aligned to our priorities and commitments.

Eddie