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@gmail.com