Open Stack

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-5ePOaSSkKD1CS27ohU/edit#gid=162080347
* 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 at gmail.com