[Starlingx-discuss] Package extraction to new repos

[Dean Troyer]

In the versioning thread Saul started yesterday[0] we started talking
about extracting more of the components of StarlingX, in particular
clients and other common dependences, in order to more easily build
and version them independently.  Let's keep the discussion of what
versions look like there and talk about the extraction stuff here...

I have done a little investigating starting with extracting
cgts-client from the config repo [1] (also renaming it in the process)
using the same process we used to split up the original monorepo; the
extraction process preserving git history is mostly automated.  That
POC also renamed the client to get a feel for how much work that is in
that context (without touching all of the references to it, much more
work!).

I have created an ethercalc[2] to explore/identify some initial
targets and set an overall direction for this work.  This is also a
good time to rename things and set a common format.  However,
spreadsheets and notepads are not always the best forums for
discussing the questions.  Here are my suggestions to start things
off:

* Extract clients and their internal dependencies and publish them to
PyPI to simplify installing them in places apart from the
controller/worker nodes.
* Prefix StarlingX-specific things published to PyPI with 'stx-' to
avoid collisions.
* Use '-lib' or '-common' in names for libraries. (We have -common
already in a number of places but for fm-common that is not the python
module name, maybe those should match?)
* The Python bit of platform-util looks to be all about the license
manager, is that still needed?  Is this just a script library
otherwise?
* I renamed cgts-client to system-client in my POC, we should find a
better name than that, should the command be renamed too?[3]

There are of course a number of process things to work out like
coordination and overlap between using the prior "embedded" code and
switching to the new "independent" code.

I have started with a story[4] but expect to write a spec covering the
process and conclusions we derive here.

dt

[0] http://lists.starlingx.io/pipermail/starlingx-discuss/2019-May/004554.html
[1] https://github.com/dtroyer/stx-system-client
[2] https://ethercalc.openstack.org/stx-repo-org
[3] Full-disclosure: I have the intention to create a StarlingXClient
similar to OpenStackClient that would follow the same command format
rules and use the command name 'stxc'.
(https://github.com/dtroyer/starlingxclient,
https://github.com/dtroyer/stxc-faultmanagement)
[4] https://storyboard.openstack.org/#!/story/2005495

-- 
Dean Troyer
dtroyer at gmail.com