StarlingX Build Sub-project
- Project Lead: Cesar Lara <firstname.lastname@example.org>
- Technical Lead: Saul Wold <email@example.com>
- Contributors: Abraham Arce Moreno <firstname.lastname@example.org>; Erich Cordoba Malibran <email@example.com>; Scott Little <Scott.Little@windriver.com>; Jason McKenna <Jason.McKenna@windriver.com>; Mingyuan Qi <Mingyuan.firstname.lastname@example.org>; Hayde Martinez <email@example.com>; Jesus Ornelas <firstname.lastname@example.org>; Mario Carrillo <email@example.com>
Every Thursday 8am PST https://zoom.us/j/342730236
Project notes https://etherpad.openstack.org/p/stx-build
Team Objective / Priorities
- Responsible for the StarlingX build system
- Short Term Priorities (2018)
- Have a documented, repeatable and reliable build process for our CI/CD automation and customers to consume
- Have a reliable set of tools to build starlingX
- Mirror Script
- Build Script
- ISO Creation script
- Long Term Priorities (2019)
Use Cases for Stxb
- Case 0A [Use prebuilt ISO]
I am an organization who is considering StarlingX. I want to download the latest release build of StarlingX to evaluate it.
- Case 0B [Basic build]:
I am an individual looking to get started with StarlingX. I want to do a build of the latest code without worrying about having to set up infrastructure (local mirror, etc). I just want to build the product and have an output I can load onto a system.
- Case 1 [Provide/sync a local mirror]:
I am an organization with a site who is working with StarlingX. I want to provide a local mirror of artifacts for my employees so they don’t have to download from the Internet. I want to create an automated job which I will run daily to update my mirror. The artifacts downloaded are to be posted to a network file share on which I have write permissions. I do not want to re-download any artifacts which I already have downloaded.
- Case 2 [Build using a local mirror]:
I am a developer within an organization which has provided a local mirror of artifacts on a network file share. I want to build StarlingX using the local mirror for any artifacts. The mirror will contain all binary rpms along with their corresponding src rpm, such that if no changes all the building of an ISO would be done from the mirror rpms, no actual local rpm build required unless it changes
- Case 3 [Rebuild with sane downloads and rebuild package list]:
I am a developer who has already performed a build with artifacts I have downloaded (case 0B). I want to perform a rebuild using the latest upstream content.
- Requirement 3A: The rebuild shall not re-download any artifacts which have not been updated.
- Requirement 3B: The rebuild shall download any artifacts which have been updated or added.
- Requirement 3C: The rebuild shall not re-build any content which has not changed since previous build
- Requirement 3D: The rebuild shall re-build any content which has changed since previous build
- Case 4 [Build with a local change to existing package]:
I am a developer who wants to make a change to an existing package within StarlingX. I want to build StarlingX with my change in place to test it. I do not want to perform a git commit or upstream my change at this time.
- Case 5 [Build with a new binary package]:
I am an organization who produces a product based on StarlingX. I want to add my own proprietary package to the ISO. I want to build the StarlingX ISO with my package included on the disk and installed on all nodes. The package is available as a prebuilt binary RPM on the build machine’s file system and has no additional package dependencies.
- Case 6 [Build with a new source package]:
I am an organization who produces a product based on StarlingX. I want to add my own proprietary package to the ISO. I want to build my package within the StarlingX framework. The source code is available in a locally accessible git.
- Case 7 [Multi-user/multi-workspace]:
I am a developer at an organization. I share a build machine with multiple other users. Furthermore, I work on several different branches/workspaces of StarlingX concurrently. I want to log into the build machine using two separate shells, each working in a separate workspace. I do not want to have to edit files in my home or system directory to select the new workspace, as this would imply that only one user/workspace can be active at a time.
- Case 8 [Branch support]:
I am a developer at an organization which produces StarlingX. A customer has reported a potential bug which they observed on the 2018.10 release build of StarlingX. I want to perform a build of r/2018.10 branch of StarlingX (rather than master) to start to debug the issue
- Case 9 [Build avoidance - organization]:
I am an organization who produces a StarlingX build nightly as an automated job. I want to provide my build artifacts to developers for build avoidance.
- Case 10 [Build avoidance – developer]:
I am a developer at an organization which produces a StarlingX nightly build. When I build my system, and I have not changed a package since my organization last did a nightly build, I want to use the pre-built version of the package rather than compile it myself.
- Case 11 [Patching]:
I am a developer at an organization which produces a StarlingX based product. I have made changes to a package to fix a bug. I want to produce a patch/update to the release ISO which will include the updated rpm.
- Unstated requirements:
- I should be able to perform all of the above without root access on the build machine
- I want to be able to work on a local copy of the source code, not have to go into a container to modify or work on code
- I would prefer if I was able to do the above on a native CentOS machine without using docker containers, but I think that ship has sailed
All story board stories and launchpad bugs created for this team should use the tag "stx.build".
Team Work Items
- Story Board
- Launchpad Bugs
- Capture status - what's the cadence? weekly?