[nova][qa] Should we make legacy-grenade-dsvm-neutron-multinode-live-migration voting?
The legacy-grenade-dsvm-neutron-multinode-live-migration job was recently fixed [1][2] but had been broken for awhile because it's non-voting so no one really noticed. The unique thing about this job is it runs live migration tests in a grenade setting where one of the computes is n-1 and it does the live migration back and forth between the nodes so we have old->new and new->old coverage, and it does this across local disk and shared storage with ceph. Now that it's working again, should we make it voting? It came up while discussing regression test coverage for Artom's NUMA live migration series. It seems like a no-brainer to me at least that we should be gating on this. Before doing that, I'd like to move the job config from openstack-zuul-jobs to nova so we "own" any changes to the job and then might also consider converting it to zuul v3, but that's not a blocker to make it voting. [1] https://review.openstack.org/#/c/634962/ [2] https://review.openstack.org/#/c/637231/ -- Thanks, Matt
On 02/28/2019 10:23 AM, Matt Riedemann wrote:
The legacy-grenade-dsvm-neutron-multinode-live-migration job was recently fixed [1][2] but had been broken for awhile because it's non-voting so no one really noticed.
The unique thing about this job is it runs live migration tests in a grenade setting where one of the computes is n-1 and it does the live migration back and forth between the nodes so we have old->new and new->old coverage, and it does this across local disk and shared storage with ceph.
Now that it's working again, should we make it voting? It came up while discussing regression test coverage for Artom's NUMA live migration series.
Sure, why not.
It seems like a no-brainer to me at least that we should be gating on this.
Before doing that, I'd like to move the job config from openstack-zuul-jobs to nova so we "own" any changes to the job and then might also consider converting it to zuul v3, but that's not a blocker to make it voting.
Cool. Will try to look at those today. Thanks for working on this, Matt. -jay
[1] https://review.openstack.org/#/c/634962/ [2] https://review.openstack.org/#/c/637231/
On Thursday, 28 February 2019 16:23:00 CET Matt Riedemann wrote:
Before doing that, I'd like to move the job config from openstack-zuul-jobs to nova so we "own" any changes to the job and then might also consider converting it to zuul v3, but that's not a blocker to make it voting.
I restarted the effort to create a native Zuul v3 grenade job; it is still WIP, it depends on bunch of patches but it is seems to be already working (need to fix the list of captured log files), but it is still need to be reviewed. You may want to try to build a job on top of it anyway, that would help to spot issues: https://review.openstack.org/#/c/548936/ Example of jobs based on the WIP grenade job: - https://review.openstack.org/#/c/639774/ - https://review.openstack.org/#/c/638390/ Ciao -- Luigi
On Thu, 28 Feb 2019 09:23:00 -0600, Matt Riedemann <mriedemos@gmail.com> wrote:
The legacy-grenade-dsvm-neutron-multinode-live-migration job was recently fixed [1][2] but had been broken for awhile because it's non-voting so no one really noticed.
The unique thing about this job is it runs live migration tests in a grenade setting where one of the computes is n-1 and it does the live migration back and forth between the nodes so we have old->new and new->old coverage, and it does this across local disk and shared storage with ceph.
Now that it's working again, should we make it voting? It came up while discussing regression test coverage for Artom's NUMA live migration series.
+1 to making it voting.
It seems like a no-brainer to me at least that we should be gating on this.
Before doing that, I'd like to move the job config from openstack-zuul-jobs to nova so we "own" any changes to the job and then might also consider converting it to zuul v3, but that's not a blocker to make it voting.
[1] https://review.openstack.org/#/c/634962/ [2] https://review.openstack.org/#/c/637231/
---- On Fri, 01 Mar 2019 00:23:00 +0900 Matt Riedemann <mriedemos@gmail.com> wrote ----
The legacy-grenade-dsvm-neutron-multinode-live-migration job was recently fixed [1][2] but had been broken for awhile because it's non-voting so no one really noticed.
The unique thing about this job is it runs live migration tests in a grenade setting where one of the computes is n-1 and it does the live migration back and forth between the nodes so we have old->new and new->old coverage, and it does this across local disk and shared storage with ceph.
Now that it's working again, should we make it voting? It came up while discussing regression test coverage for Artom's NUMA live migration series.
It seems like a no-brainer to me at least that we should be gating on this.
Before doing that, I'd like to move the job config from openstack-zuul-jobs to nova so we "own" any changes to the job and then might also consider converting it to zuul v3, but that's not a blocker to make it voting.
+1 on making it voting. This job is only used in nova so moving it in nova tree make sense. -gmann
[1] https://review.openstack.org/#/c/634962/ [2] https://review.openstack.org/#/c/637231/
--
Thanks,
Matt
On 2/28/2019 9:23 AM, Matt Riedemann wrote:
Now that it's working again, should we make it voting? It came up while discussing regression test coverage for Artom's NUMA live migration series.
It seems like a no-brainer to me at least that we should be gating on this.
Before doing that, I'd like to move the job config from openstack-zuul-jobs to nova so we "own" any changes to the job
Just an update on this. The series of changes are here [1]. The immediate changes to care about are making the job voting on master [2] (already approved) which depends on moving it in-tree [3] (needs approval). The stable/rocky change [4] should also be good to go now. After that it gets a bit messy with stable/queens because of trying to fix bug 1813216 there which is extra complicated because that involves configuring nova-compute and in stable/queens grenade, we have one compute (from pike) using nova.conf and one compute from queens using nova-cpu.conf, and our grenade live migration ceph setup script isn't handling that wackiness today. I have ideas on fixing the stable/queens stuff but it's going to have to wait until after stein feature freeze when things settle down. But it'd be good to get the master change in before we cut stable/stein so I don't have to do another backport. [1] https://review.openstack.org/#/q/status:open+topic:nova-grenade-live-migrati... [2] https://review.openstack.org/#/c/640182/ [3] https://review.openstack.org/#/c/640181/ [4] https://review.openstack.org/#/c/640191/ -- Thanks, Matt
participants (5)
-
Ghanshyam Mann
-
Jay Pipes
-
Luigi Toscano
-
Matt Riedemann
-
melanie witt