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.