> -----Original Message----- > From: Jay Pipes [mailto:jaypi...@gmail.com] > Sent: Friday, March 25, 2016 10:20 PM > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [nova] The same SRIOV / NFV CI failures missed a > regression, why? > > On 03/24/2016 09:35 AM, Matt Riedemann wrote: > > We have another mitaka-rc-potential bug [1] due to a regression when > > detaching SR-IOV interfaces in the libvirt driver. > > > > There were two NFV CIs that ran on the original change [2]. > > > > Both failed with the same devstack setup error [3][4]. > > > > So it sucks that we have a regression, it sucks that no one watched > > for those CI results before approving the change, and it really sucks > > in this case since it was specifically reported from mellanox for > > sriov which failed in [4]. But it happens. > > > > What I'd like to know is, have the CI problems been fixed? There is a > > change up to fix the regression [5] and this time the Mellanox CI > > check is passing [6]. The Intel NFV CI hasn't reported, but with the > > mellanox one also testing the suspend scenario, it's probably good enough. > > From the commit message of the original patch that introduced the > regression: > > "This fix was tested on a real environment containing the above type of VMs. > test_driver.test_detach_sriov_ports was slightly modified so that the VIF from > which data is sent to _detach_pci_devices will contain the correct SRIOV > values > (pci_slot, vlan and hw_veb VIF type)" > > I'm not sure if the above statement could ever have been true considering the > AttributeError that occurred in the bug... > > In any case, I think that it's pretty clear that the CI systems for NFV and > PCI > have been less than reliable at functionally testing the PCI and NFV-specific > functionality in Nova. > > This isn't trying to put down the people that work on those systems -- I know > first hand that it can be difficult to build and maintain CI systems that > report in > to upstream, and I appreciate the effort that goes into this. > > But, going forward, I think we need to do something as a concerned > community. > > How about this for a proposal? > > 1) We establish a joint lab environment that contains heterogeneous hardware > to which all interested hardware vendors must provide hardware. > > 2) The OpenStack Foundation and the hardware vendors each foot some > portion of the bill to hire 2 or more systems administrators to maintain this > lab > environment. > > 3) The upstream Infrastructure team works with the hired system > administrators to create a single CI system that can spawn functional test > jobs > on the lab hardware and report results back to upstream Gerrit > > Given the will to do this, I think the benefits of more trusted testing > results for > the PCI and SR-IOV/NFV areas would more than make up for the cost. +1 I like this proposal. We can help by providing Mellanox hardware and share our CI knowledge.
> > Best, > -jay > > ________________________________________________________________ > __________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev