Welcome to the MultiOS sub-project!
- Project Lead: Cesar Lara (<email@example.com>)
- 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, Cesar Lara, Scott Little, Abraham Arce Moreno, Bruce Jones
Every Monday 4PM Pacific time https://zoom.us/j/342730236
Project notes https://etherpad.openstack.org/p/stx-multios
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 easier as the Upstreaming project gets the StarlingX forks closed.
- 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 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 uses systemd for many services such as cron, syslog, ntp, initscript. We will need to look at longer term support of individual services vs systemd
Clear Linux high level plan
This is a plan for doing a demo of StarlingX services running on Clear Linux with almost no thought to functionality. It is a science project intended to help discover additional issues (beyond those above) regarding running StarlingX on Clear. This work will also likely lead us into StarlingX architecture issues as Clear Linux doesn't support all of the technologies used in StarlingX. This work is intended to raise those issues, not resolve them.
- Get DevStack running on top of Clear and demo it. This should be covered by the Devstack Integration sub-project.
- 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:
- Create a specification for this work and get it reviewed and approved
- 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
- Create package git repos and RPM spec files for a TBD set of additional components (the ones we patch - with their patch files) - as needed by the StarlingX services
- 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
- Get the build working in the per-company Koji. "Working" means that the RPM packages are produced
- Create Clear Linux bundles from the RPM packages and a Clear Linux Mix-in to create images
- Demo running the services, showing responses to basic API commands.
- Next steps to be determined...
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.
Ubuntu high level plan