OVS Testing in the Community Lab

[Adam Hassick]

On Tue, Mar 19, 2024 at 3:28 PM Aaron Conole <aconole at redhat.com> wrote:
>
> Adam Hassick <ahassick at iol.unh.edu> writes:
>
> > Hi Aaron,
> >
> > I'm working on enabling OVS testing in the community lab. Currently, I
> > have a compile test set up which follows the steps defined in the OVS
> > documentation (https://docs.openvswitch.org/en/latest/intro/install/dpdk/)
> > and consumes the shared libraries produced by the DPDK native GCC
> > compile test that we run. This way, we can save some compute resources
> > by not compiling DPDK an additional time. However, this will mean that
> > the OVS compile test will not run if the DPDK compile test fails in
> > any environment, but I think that behavior is acceptable. What do you
> > think?
>
> That is acceptable.  However, we probably want to be a bit careful about
> it because as DPDK changes, there may be some kind of API break that OVS
> needs to know about.  In that case, we might consider using the
> dpdk-latest branch of ovs rather than ovs master.

Ok, when running periodic tests on main we will use the dpdk-latest
branch of OVS. Do you think we should include this test for incoming
patches or just run periodic on main? If the OVS maintainers are
interested in seeing these results, then we could send result emails
to one of their mailing lists as well.

> > The OVS compile test has passed successfully with DPDK main, which is promising.
> >
> > I'm unsure what the scope of our testing should be as well. Should we
> > run the compile tests on all of our VM/container environments (to get
> > good distro coverage), or just a few? And should we only run periodic
> > testing on main or include LTS, next-* branches?
>
> This is a good question.  OVS sticks with LTS branches, mostly, because
> those are the ones which are "stable" from a maintenance standpoint.  So
> we're probably mostly going to build from dpdk stable branches.

I see that OVS has a table of compatibility for DPDK LTS and OVS
releases. Maybe we can start with periodic testing between these
compatible releases and move forward from there.

> > Regards,
> > Adam
>