The packaging of stx-gui is complete.
The panels present in stx-gui are packaged as starlingx-dashboard and included in the iso build. The manual steps listed below are no longer required, everything is integrated into the build
process.
David
From: Ramirez, Eddie [mailto:eddie.ramirez@intel.com]
Sent: Wednesday, August 22, 2018 9:43 PM
To: starlingx-discuss@lists.starlingx.io
Subject: [Starlingx-discuss] The stx-gui challenge
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
What does NOT the plugin do?
How do I use it?
The steps below are ONLY for development and assuming you’re developing outside of the VM running StarlingX.
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