Jump to: navigation, search


< StarlingX
Revision as of 21:01, 20 September 2018 by Bruce.e.jones (talk | contribs) (Clear Linux high level plan)

MultiOS Sub-project

Welcome to the MultiOS sub-project!

Team members

  • Project Lead: TBD. Candidates are: Bruce Jones, Cindy Xie, Dariush Eslimi
  • Technical Lead : TBD. Candidates are: Brent Rowsell, Saul Wold
  • Contributors: Saul Wold, Dean Troyer, Mario Alfredo C Arevalo, Jesus Ornelas Aquayo, Yong Hu, Yi C Wang; Yan Chen; Mingyuan Qi

Weekly call



Our goals for this sub-project are:

  • Enable StarlingX to be built on and run on multiple host operating systems
    • Our initial target operating systems are CentOS (currently supported), Clear Linux and Ubuntu
  • Enable StarlingX to provide software management services for multiple package file formats
    • This requires building abstraction layers in the StarlingX Flock to allow package management to be defined per-OS (or per package manager)


This work is dependent on work being done in the Python2 to Python3 Transition| and Devstack Integration sub-projects, and will become much easier as the Upstreaming project gets the StarlingX forks closed.

Work items

  • All Storyboard stories created for this team should use the tag "stx.multios" and the prefix [MultiOS].
  • The work items for this team can be found in Storyboard here.
  • The bugs open against the project can be found in TBD

Operating Sysem Dependent Notes and Issues

Clear Linux

Clear Linux issues
  • Clear Linux does not support Python2. StarlingX contains Python2 code. Work to remove it is tracked in the Python2 project. Note that Glance and Ironic are not Python3 compliant in OpenStack Pike!
  • StarlingX is tightly coupled to a patched version of CentOS for features, stability and performance. Getting the patches accepted upstream is in progress, which will help making StarlingX OS independent. Additional work beyond patch upstreaming will likely be needed.
  • StarlingX is relies on controlling the RPM versions of the packages we build against and use at run-time. Work is needed to allow RPM package versions to "float". Additional work will be needed on a package by package basis to ensure StarlingX works reliably with new versions of packages.
  • StarlingX is tightly coupled to a patched version of OpenStack and the same issues/solution apply as for the CentOS coupling.
  • StarlingX is reliant on the RPM packaging system. Clear Linux is also based on RPMs.
  • Clear Linux support for OpenStack is work in progress. Any support provided would be based on OpenStack's latest release, StarlingX is currently on Pike.
  • The test infrastructure and test cases for StarlingX are currently minimal. Our ability to test the project in the face of the large changes needed to integrate with Clear Linux is currently limited.
  • Clear Linux does not provide all of the RPM packages needed to build or run StarlingX
  • StarlingX relies on installation automation that may not exist within Clear Linux
  • StarlingX makes extensive use of puppet, which may not be supported by Clear Linux
Clear Linux high level plan
  1. Get DevStack running on top of Clear and demo it. This should be covered by the Devstack Integration sub-project.
  2. Build the Flock services against Clear Linux, such that they run without failing and respond to API calls, and demo it. StoryBoard stories are needed for the following:
    1. Create a specification for this work and get it reviewed and approved
    2. Create the "package git" repositories for the Flock in the StarlingX-staging github. In Clear each RPM spec file lives in its own repo, to build using Clear we must follow their practice
    3. Create RPM spec files for each package git that pull their dependencies from Clear Linux upstream
    4. Create package git repos and RPM spec files for a TBD set of additional components (the ones we patch - with their patch files)
    5. Create scripting / setup / configuration to allow teams to build a per-company (shared) Koji environment to build the Flock services from the package git repos
    6. Get the build working in the per-company Koji. "Working" means that the RPM packages are produced
    7. Create Clear Linux bundles from the RPM packages and/or a Clear Linux Mixer if needed.
    8. Demo the installation of StarlingX from a bundle ("swupd starlingx") and run the services, showing responses to basic API commands.
  3. Next steps to be determined...


Ubuntu issues

Problems that need to be solved in this integration include:

  • Ubuntu is built from .deb packages and uses Debian package management tools. StarlingX is currently hard-coded with RPM packages and tools.
  • TBD...
Ubuntu high level plan
  • TBD...