Overall plan and status tracking document: https://etherpad.openstack.org/p/stx-openstack-patch-refactoring

· Details: https://docs.google.com/spreadsheets/d/1udAtEpQljV2JZVs-525UhWyx-5ePOaSSkKD1CS27ohU/edit?usp=sharing

Story boards: https://storyboard.openstack.org/#!/story/list?status=active&tags=stx.distro.openstack&project_group_id=86

Meeting agenda and notes for the 3/19 meeting

· 3/12 email from Dean:

• This is the process I imagined and outlined in the meeting:

§ When Nova creates their stable/stein branch at RC1 time (week of Mar 19th) we will create a mirror of that in starlingx-staging/nova as stx/stein.

§ AR Dean to pull our branch next week, to be populated from backports

· 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.

· We can switch Sanity testing to the new branch.

· We would have to update / add Zuul jobs to allow the already defined Nova Zuul jobs to run out of github staging

· We would have to add a trigger to the github to watch PRs and start Zuul

§ 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)

· Do we rebase backports?

· We think that the right approach will be to take these as they come in.  Make it easy on the developers.  Concern is about how to manage conflicts with upstream Nova changes.

· How frequently do we rebase?  Weekly?  When we need to?  At the very least we want to do one rebase just before code freeze (and after stable Stein is released).

· We marked up the spreadsheet with a new "Candidate for backport" column and identified 11 changes that are candidates

· NUMA live migration WIP code - can/should we jumpstart integration of it with STX?

• Code upstream is in reasonable shape and needs two small fixes.  Gerry @ WR has been testing it against pinning / not pinned, hugepages vs none.  Gerry has posted review comments with suggested fixes.

• Bruce to stop the work in SH on this and let Gerry drive.

• Dean to post a message to Nova calling out our need for a fork and would like to minimize it, by asking that the changes we want hit Train early.

· Re: https://review.openstack.org/#/c/641908/ - this didn't get a launchpad filed, so the Nova community (Matt R) put a -2 on the review since it looks like a new feature.