Hi Ales On Wed, Jan 21, 2026 at 9:15 AM Ales Musil <[email protected]> wrote:
> > > On Wed, Jan 21, 2026 at 9:12 AM Xavier Simonart <[email protected]> > wrote: > >> Hi Ales >> >> Thanks for looking into this. >> >> On Wed, Jan 21, 2026 at 8:40 AM Ales Musil <[email protected]> wrote: >> >>> >>> >>> On Mon, Jan 19, 2026 at 2:15 PM Xavier Simonart via dev < >>> [email protected]> wrote: >>> >>>> This will tag tests for which upgrade tests would fail. >>>> This is a pre-requisite for upgrade test patch [1]. >>>> When upgrade tests (from [1]) are run, tests tagged with >>>> TAG_TEST_NOT_UPGRADABLE will be skipped. >>>> >>>> The "NOT_UPGRADABLE" test would fail since patch [2] added a >>>> new table, which is unexpected by the old test. >>>> >>>> [1] ci: Run system tests in upgrade scenario >>>> [2] controller: Learn EVPN workload FDB from the ingress traffic >>>> >>>> Signed-off-by: Xavier Simonart <[email protected]> >>>> --- >>>> >>> >>> Hi Xavier, >>> >>> thank you for the patch. I think this is a little wrong way of doing >>> this. >>> We should have this patch on main first and then backport it. >>> After that we can proceed with the upgrade testing, would you agree? >>> >> I am not sure. >> >> The upgrade test fails to upgrade to main. So, the tag itself >> (TAG_TEST_NOT_UPGRADABLE >> in system-ovn.at) should only be set in this branch. It should not be >> set on main. >> Of course, we could have this patch on main, backport it to this branch >> only, and then the upgrade patch itself, in main, would also remove the tag >> from the test. >> WDYT? >> By the way, the fact that this patch is not (yet) in github branch-25.09 >> is the reason why the upgrade test failed ( >> https://github.com/ovsrobot/ovn/actions/runs/21139194130) >> > > I was referring mainly to the addition of the tag itself, but having a > custom backport of the tag as it's this patch here would solve that. So > what I'm thinking of is a patch that adds the tag on main, then this custom > backport that also adds it to the test on 25.09, that will refer to > the patch on main. Does that make more sense? > Yes, I think it makes sense . This way this patch (with macro change and no system-test change) has a reference on main, can be custom backported (with macro change + system-test change) and we do not set/unset the tag in system-test on main which was kind of overkill. Thanks Xavier > > >> Thanks >> Xavier >> >> >>> >>>> tests/ovn-macros.at | 6 ++++++ >>>> tests/system-ovn.at | 1 + >>>> 2 files changed, 7 insertions(+) >>>> >>>> diff --git a/tests/ovn-macros.at b/tests/ovn-macros.at >>>> index 94a0d61ef..0b8599d31 100644 >>>> --- a/tests/ovn-macros.at >>>> +++ b/tests/ovn-macros.at >>>> @@ -1493,6 +1493,12 @@ m4_define([TAG_UNSTABLE], [ >>>> AT_SKIP_IF([test X"$SKIP_UNSTABLE" = Xyes]) >>>> ]) >>>> >>>> +# TAG_TEST_NOT_UPGRADABLE tag indicates that the test would fail >>>> +# "upgrade" test (i.e. running old ovn-northd and new ovn-controller) >>>> +m4_define([TAG_TEST_NOT_UPGRADABLE], [ >>>> + AT_SKIP_IF([test X"$UPGRADE_TEST" = Xyes]) >>>> +]) >>>> + >>>> m4_define([OVN_CHECK_SCAPY_EDNS_CLIENT_SUBNET_SUPPORT], >>>> [ >>>> AT_SKIP_IF([test $HAVE_SCAPY = no]) >>>> diff --git a/tests/system-ovn.at b/tests/system-ovn.at >>>> index 6aca7b7df..efe6ff545 100644 >>>> --- a/tests/system-ovn.at >>>> +++ b/tests/system-ovn.at >>>> @@ -17500,6 +17500,7 @@ AT_CLEANUP >>>> OVN_FOR_EACH_NORTHD([ >>>> AT_SETUP([dynamic-routing - EVPN]) >>>> AT_KEYWORDS([dynamic-routing]) >>>> +TAG_TEST_NOT_UPGRADABLE >>>> >>>> CHECK_VRF() >>>> CHECK_CONNTRACK() >>>> -- >>>> 2.47.1 >>>> >>>> _______________________________________________ >>>> dev mailing list >>>> [email protected] >>>> https://mail.openvswitch.org/mailman/listinfo/ovs-dev >>>> >>>> >>> Regards, >>> Ales >>> >> _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
