* OVS Testing in the Community Lab
@ 2024-03-15 15:19 Adam Hassick
2024-03-19 19:27 ` Aaron Conole
0 siblings, 1 reply; 4+ messages in thread
From: Adam Hassick @ 2024-03-15 15:19 UTC (permalink / raw)
To: Aaron Conole; +Cc: ci, Patrick Robb
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?
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?
Regards,
Adam
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: OVS Testing in the Community Lab
2024-03-15 15:19 OVS Testing in the Community Lab Adam Hassick
@ 2024-03-19 19:27 ` Aaron Conole
2024-03-19 21:04 ` Adam Hassick
0 siblings, 1 reply; 4+ messages in thread
From: Aaron Conole @ 2024-03-19 19:27 UTC (permalink / raw)
To: Adam Hassick; +Cc: ci, Patrick Robb, David Marchand, Kevin Traynor
Adam Hassick <ahassick@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.
> 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.
> Regards,
> Adam
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: OVS Testing in the Community Lab
2024-03-19 19:27 ` Aaron Conole
@ 2024-03-19 21:04 ` Adam Hassick
2024-03-20 14:47 ` Aaron Conole
0 siblings, 1 reply; 4+ messages in thread
From: Adam Hassick @ 2024-03-19 21:04 UTC (permalink / raw)
To: Aaron Conole; +Cc: ci, Patrick Robb, David Marchand, Kevin Traynor
On Tue, Mar 19, 2024 at 3:28 PM Aaron Conole <aconole@redhat.com> wrote:
>
> Adam Hassick <ahassick@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
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: OVS Testing in the Community Lab
2024-03-19 21:04 ` Adam Hassick
@ 2024-03-20 14:47 ` Aaron Conole
0 siblings, 0 replies; 4+ messages in thread
From: Aaron Conole @ 2024-03-20 14:47 UTC (permalink / raw)
To: Adam Hassick; +Cc: ci, Patrick Robb, David Marchand, Kevin Traynor
Adam Hassick <ahassick@iol.unh.edu> writes:
> On Tue, Mar 19, 2024 at 3:28 PM Aaron Conole <aconole@redhat.com> wrote:
>>
>> Adam Hassick <ahassick@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.
That would be good.
BTW - this used to run at the lab, you can see the presentation:
https://www.youtube.com/watch?v=ZhQY_4SrvmI
>> > Regards,
>> > Adam
>>
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2024-03-20 14:47 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-03-15 15:19 OVS Testing in the Community Lab Adam Hassick
2024-03-19 19:27 ` Aaron Conole
2024-03-19 21:04 ` Adam Hassick
2024-03-20 14:47 ` Aaron Conole
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).