[openstack-dev] CI for NUMA, SR-IOV, and other features that can't be tested on current infra.

Joe Gordon joe.gordon0 at gmail.com
Tue Nov 18 22:54:23 UTC 2014


On Sun, Nov 16, 2014 at 5:31 AM, Irena Berezovsky <irenab at mellanox.com>
wrote:

> Hi Steve,
> Regarding SR-IOV testing, at Mellanox we have CI job running on bare metal
> node with Mellanox SR-IOV NIC.  This job is reporting on neutron patches.
> Currently API tests are executed.
> The contact person for SRIOV CI job is listed at driverlog:
>
> https://github.com/stackforge/driverlog/blob/master/etc/default_data.json#L1439
>


>
> The following items are in progress:
>  - SR-IOV functional testing
>

Where do you envision these tests living?


>  - Reporting CI job on nova patches
>

Looking forward to it. I assume you will be working with the other people
trying to set up assorted CI systems in this space.


>  - Multi-node setup
> It worth to mention that we   want to start the collaboration on SR-IOV
> testing effort as part of the pci pass-through subteam activity.
> Please join the weekly meeting if you want to collaborate or have some
> inputs: https://wiki.openstack.org/wiki/Meetings/Passthrough
>
> BR,
> Irena
>
> -----Original Message-----
> From: Steve Gordon [mailto:sgordon at redhat.com]
> Sent: Wednesday, November 12, 2014 9:11 PM
> To: itai mendelsohn; Adrian Hoban; Russell Bryant; Ian Wells (iawells);
> Irena Berezovsky; baoli at cisco.com
> Cc: Nikola Đipanov; Russell Bryant; OpenStack Development Mailing List
> (not for usage questions)
> Subject: [Nova][Neutron][NFV][Third-party] CI for NUMA, SR-IOV, and other
> features that can't be tested on current infra.
>
> Hi all,
>
> We had some discussions last week - particularly in the Nova NFV design
> session [1] - on the subject of ensuring that telecommunications and
> NFV-related functionality has adequate continuous integration testing. In
> particular the focus here is on functionality that can't easily be tested
> on the public clouds that back the gate, including:
>
> - NUMA (vCPU pinning, vCPU layout, vRAM layout, huge pages, I/O device
> locality)
> - SR-IOV with Intel, Cisco, and Mellanox devices (possibly others)
>
> In each case we need to confirm where we are at, and the plan going
> forward, with regards to having:
>
> 1) Hardware to run the CI on.
> 2) Tests that actively exercise the functionality (if not already in
> existence).
> 3) Point person for each setup to maintain it and report into the
> third-party meeting [2].
> 4) Getting the jobs operational and reporting [3][4][5][6].
>
> In the Nova session we discussed a goal of having the hardware by K-1 (Dec
> 18) and having it reporting at least periodically by K-2 (Feb 5). I'm not
> sure if similar discussions occurred on the Neutron side of the design
> summit.
>
> SR-IOV
> ======
>
> Adrian and Irena mentioned they were already in the process of getting up
> to speed with third party CI for their respective SR-IOV configurations.
> Robert are you attempting similar with regards to Cisco devices? What is
> the status of each of these efforts versus the four items I lifted above
> and what do you need assistance with?
>
> NUMA
> ====
>
> We still need to identify some hardware to run third party CI for the
> NUMA-related work, and no doubt other things that will come up. It's
> expected that this will be an interim solution until OPNFV resources can be
> used (note cdub jokingly replied 1-2 years when asked for a "rough"
> estimate - I mention this because based on a later discussion some people
> took this as a serious estimate).
>
> Ian did you have any luck kicking this off? Russell and I are also
> endeavouring to see what we can do on our side w.r.t. this short term
> approach - in particular if you find hardware we still need to find an
> owner to actually setup and manage it as discussed.
>
> In theory to get started we need a physical multi-socket box and a virtual
> machine somewhere on the same network to handle job control etc. I believe
> the tests themselves can be run in VMs (just not those exposed by existing
> public clouds) assuming a recent Libvirt and an appropriately crafted
> Libvirt XML that ensures the VM gets a multi-socket topology etc. (we can
> assist with this).
>
> Thanks,
>
> Steve
>
> [1] https://etherpad.openstack.org/p/kilo-nova-nfv
> [2] https://wiki.openstack.org/wiki/Meetings/ThirdParty
> [3] http://ci.openstack.org/third_party.html
> [4] http://www.joinfu.com/2014/01/understanding-the-openstack-ci-system/
> [5]
> http://www.joinfu.com/2014/02/setting-up-an-external-openstack-testing-system/
> [6]
> http://www.joinfu.com/2014/02/setting-up-an-openstack-external-testing-system-part-2/
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141118/665d38d6/attachment.html>


More information about the OpenStack-dev mailing list