[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Wg-test-framework] Minutes of monthly Xen+Libvirt OpenStack meeting (Match 25th)
Lars Kurth wrote: > LK :asks what Xen + Libvirt baseline we are using > > BB: at the moment we have a custom based system which uses Xen 4.4.2 > (with some of JF's patches) + Ubuntu Dom0 + an older libvirt version > with some patches. > BB: we were also queuing up Daniel B's fix (aka 159106 > <https://review.openstack.org/#/c/159106>). We can easily add > openstack changes that are necessary into the custom config. > > LK wonders whether the randomness of failures are an indicator that we > are suffering from the concurrency issues that JF is investigating > > JF: has been looking at running Tempest in parallel. Whether the > intermittent failures would be improved is not clear. > > BB: Even within serial Tempest, multiple VMs are run and thus it is > plausible that the intermittend failures could be caused by this. > > JF: if VM's are started/destroyed concurrently we could be hitting the > issues that have been fixed. > JF: I've made some progress on the concurrency problems Tempest (and > my reproducer) bump into. > > JF: sent mail with additional patches for Xen 4.4 & 4.5 and Libvirt > (yesterday several patches) were committed. > > [Copy of text from JF's e-mail sent prior to the meeting > > > On the Xen side, 5 patches are needed on top of current 4.4.x and > 4.5.x. Commits 93699882d and f1335f0d from master and 4783c99a, > 1c91d6fba, and 188e9c54 from staging. > > A lot of work has been done on the libvirt side, much of which has > been > committed. I do have one last series of three patches fixing issues > related to domain destroy that are not yet posted upstream. With > those > patches on top of current libvirt.git master, and a libxl containing > aforementioned Xen patches, my Tempest reproducer passes. > > ] > > LK: asks how easy it is to change the Xen and Libvirt baseline > > BB: Not particularly straight forward, unless we can upgrade for all > of the tests. > BB: We can't run a single test with a custom version with libvirt or > Xen. Would have change for all tests. > > LK: given the intermittent failures changing the Xen + Libvirt > baseline would actually > > AP: Testing a specific version of Xen 4.4.1 + additional patches and > Libvirt plus patches > AP: Tried JF's new patches on his local set-up in parallel, and still > gets many time-outs. Anthony, did your local setup include the five libxl patches I mentioned (and Lars pasted above)? To test Tempest in parallel, I'd suggest using a Xen that includes the five libxl patches and libvirt.git master plus this series https://www.redhat.com/archives/libvir-list/2015-March/msg01337.html > LK: It appears that moving the baseline for Xen and Libvirt and > getting the NOVA changes in are our top next steps > > **ALL AGREED* * > > Bob: XenServer had an internal CI loop for quite some time before > going live and achieving a good level of pass rates. > > Bob: would be happy to move the baseline > > ACTION: JF & AP to decide what the best baseline would be > > LK: asks what test environment JF uses > > JF: doesn't run Tempest, runs his own Tempest reproducer > JF: the Xen version does not appear to matter so much as long as the 5 > patches are in place > (4.4.2 + 4.5 + unstable with those 5 patches listed above). All > of these work equally well with reproducer scripts. > JF: Will ask Xen maintainers to back port these such that the next Xen > releases have the fixes in them > > JF: Libvirt needs to use something very current. The latest release is > not sufficient. It needs to be git master. > JF: points out that libvirt 1.4.14 (released in 2 weeks) will contain > all the recent libvirt work Minor correction: libvirt 1.2.14 will be released on April's Fools Day :-). Regards, Jim _______________________________________________ Wg-test-framework mailing list Wg-test-framework@xxxxxxxxxxxxxxxxxxxx http://lists.xenproject.org/cgi-bin/mailman/listinfo/wg-test-framework
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |