[Starlingx-discuss] Distro.openstack meeting notes Mar 12th 2019
Meeting agenda and notes for the 3/12 meeting * Good news - Neutron network segment range patches in (except lib) * Bad news - NUMA topology pushed out. * We believe we will have to carry forks of at least some of the Nova changes * We also believe anything committed to Nova is deployable (and will remain so as per Matt R). * We should implement the "upstream first" and "stable branch" concept and backport critical features and features from Train to our release branch ? Changes that are absolutely critical should be backported before they are accepted (and updated over time until acceptance). ? We should help fix things upstream as we find issues with Train "work in progress" patches * Meanwhile we will continuously update our master from OpenStack master * AR Bruce and Frank - need a plan for upstream contributions for Nova * We need to define our branching strategy. Create an f/stx-stein branch? Create a f/nova feature branch for StarlingX? * We will need to build our Nova container out of the github staging trees - once Nova cuts there first RC (Mar 22nd). Backports will be checked into github directly. * Plan to raise these issues with Nova community at PTG and support the efforts * Review updates: https://docs.google.com/spreadsheets/d/1udAtEpQljV2JZVs-525UhWyx-5ePOaSSkKD1... * Review LP issues: https://bugs.launchpad.net/starlingx/+bugs?field.tag=stx.distro.openstack
On Tue, Mar 12, 2019 at 8:55 AM Jones, Bruce E <bruce.e.jones@intel.com> wrote: [...]
· We need to define our branching strategy. Create an f/stx-stein branch? Create a f/nova feature branch for StarlingX? We will need to build our Nova container out of the github staging trees - once Nova cuts there first RC (Mar 22nd). Backports will be checked into github directly.
This is the process I imagined and outlined in the meeting: * When Nova creates their stable/stein branch at RC1 time we will create a mirror of that in starlingx-staging/nova as stx/stein. * This branch will be periodically updated from stable/stein as backports appear there from the Nova team. * As items on our list of upstream changes land in master (Train) we will backport them to stx/stein for StarlingX to pick up. * There may be times that work upstream has not yet merged but is sufficiently complete that we would backport early to meet a StarlingX time requirement, with the expectation that it be brought current with what finally does merge after that happens. * Upstream work that is not yet complete that we want to backport to meet a StarlingX time requirement should be worked upstream to get it to the state mentioned above to enable us to backport it to stx/stein. Still to be decided/confirmed: * We need to have some measure of testing in stx/stein, I will look in to what we can run from OpenStack Zuul directly. * I like the idea of continuing to have only a small number of people with the ability to commit to the staging repo * We may want to consider the tactic of keeping our additional commits in stx/stein rebased on top of the upstream stable/stein rather than merging in upstream backports. This would be inconvenient for those with local copies of the branch after each rebase but it would keep the SHAs in the upstream commits the same. (I am not convinced yet that we should do this, still sorting it out) dt -- Dean Troyer dtroyer@gmail.com
participants (2)
-
Dean Troyer
-
Jones, Bruce E