Last fall the StarlingX TSC approved a change in direction for the project that eliminated the use of private forks of OpenStack projects in favor of directly consuming upstream releases. This entailed a combination of upstreaming certain functionality and bug fixes from the original private forks and simply eliminating the dependency on other changes. In February StarlingX introduced a Kubernetes-based controller architecture that now deploys containerized OpenStack services built using OpenStack Helm and Airship's Armada. The upstreaming effort is still in progress with 31 items across 5 projects complete (or expected to still make Stein) and 20 items remaining to be completed, all in Nova. In preparing for the May release of StarlingX we have identified from this list of 20 items 3 features and 8 bug fixes as critical for the release. The StarlingX TSC is still committed to an upstream-first development process even though we did not reach our targets for Stein. In order to still have a widely usable May release we decided to maintain a branch of Nova Stein where we can backport these critical items as they are merged into Nova master during the Train development cycle. Aside from these 11 potential items[0] this branch will track upstream stable/stein. This branch will be hosted in the existing starlingx-staging/stx-nova repo[1] and I plan to enable a subset of Zuul testing there. The previous master branch will be renamed to stx/old-master in order to sync both master and stable/stein from upstream openstack/nova. So how is this different from the prior forks carried by StarlingX and its predecessor? * There are specific rules for what will be added to stable/stein beyond the upstream backport policy. * It is a one-time thing and the need goes away when these items are released in Train. Why did we choose to not just consume Nova master until Train is released? Of all OpenStack projects, Nova is arguably in the best position for anyone to just 'run from master'. However, the upcoming release of StarlingX is the first one using Kubernetes and has enough potential risk that we want everything else to be as stable as possible. StarlingX also has a long testing cycle since it is a top-to-bottom integrated project and having a core component changing regularly concerns our test and support teams. We will continue to work to complete the upstream items as early in the Train cycle as possible. If you have any questions or concerns please reply here, contact me or anyone on the StarlingX TSC, or find us in IRC at #starlingx. dt [0] The work items are listed in the 'Stein Backport Items' tab of the following spreadsheet: https://docs.google.com/spreadsheets/d/1udAtEpQljV2JZVs-525UhWyx-5ePOaSSkKD1... * The last item marked for Glance and Cinder is out of scope here, it is work in a StarlingX project repo [1] https://github.com/starlingx-staging/stx-nova -- Dean Troyer dtroyer@gmail.com