[Starlingx-discuss] Distro.openstack meeting Apr 10 2019

Shuquan Huang huang.shuquan at 99cloud.net
Fri Apr 12 06:22:50 UTC 2019


Hi Bruce,

These 2 fixes have been backported to stein branch at 4/11. Let’s make sure stx stein sync up to the latest stable stein.
https://review.openstack.org/#/c/649320/ <https://review.openstack.org/#/c/649320/>
https://review.openstack.org/#/c/649319/ <https://review.openstack.org/#/c/649319/>

Other fixes depends on “NUMA aware live migration”. After Gerry backport the patches from Artom, it should be fixed. We’ll validate it afterwards.



On Apr 9, 2019, at 9:27 PM, Jones, Bruce E <bruce.e.jones at intel.com> wrote:

Meeting notes and agenda for the 4/10 meeting
·         We took a decision at the release planning meeting to integrate the partially complete NUMA live migration patches from Artom into the f/stein branch to de-risk the feature.  Gerry to backport and add his fixes. Bill to get an update on the status of this.
·         Are there any other changes from the upstream list that are also that important?
·         Dean's email from 4/5:
I just finished resetting the stx-nova repo [0] to track upstream nova:
* the old master branch is now stx/old-master for reference
* master branch is a snapshot of upstream master as of about 30 min ago
* stable/stein branch is a snapshot of upstream stable/stein as of about 30 min ago
* stx/stein is our working copy of stable/stein and where anything we backport should land.
Big Note: I am thinking about keeping a policy of periodically rebasing stx/stein on stable/stein to keep a clear history as we move forward, making it easier to see what we have added.  That possibly means doing it next week when the final stein tag is added.  Thoughts?
 Force pushes can be inconvenient for developers but I am thinking the price may be worth the return on a wider scale.
·         Chris replied:
I like the idea of rebasing periodically to keep our changes "on top".
Rather than force-pushing, it might make sense to create a new branch for each of these rebases.  That way we don't need to rewrite history.
·         We agreed that we would create a new branch every time we pick up a new change, picking up the new upstream every time (even with other changes).  This requires a build change every time but is consistent with how we are handling other similar packages e.g. Ceph.  New branches to be f/stein.1/.2/.3 etc...
·         Have the NUMA changes from upstream been backported to the branch?  Any links to reviews or stories?  Bill to provide from Gerry.
·         99 Cloud sent an email update:
AR Bruce to ping Eric on getting eyeballs on rdb disk reviews and a couple others that look ready to go
Bruce to update the master spreadsheet from the email update
Shuquan to check if the fixes for "Fix stale RequestSpec instance numa topology for live-migration" are in the Stein branch (or need to be backported)
Dean to create a f/stein.1 branch for the NUMA live migration backport from Gerry.
 
 
_______________________________________________
Starlingx-discuss mailing list
Starlingx-discuss at lists.starlingx.io <mailto:Starlingx-discuss at lists.starlingx.io>
http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss <http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.starlingx.io/pipermail/starlingx-discuss/attachments/20190412/38fce055/attachment.html>


More information about the Starlingx-discuss mailing list