16:17 <imaximets> Hello there.

16:17 <imaximets> It's time for the weekly OVN meeting.

16:17 <fnordahl> o/

16:18 <imaximets> I'm not sure if we have a lot of people today. I think Mark is not here and Dumitru as well.

16:18 <imaximets> There are some holidays coming up in US, so not sure if we'll get a lot of people from there.

16:18 <imaximets> I'll start and we'll go from there.

16:18 <_lore_> hi all

16:19 <imaximets> I do not really have much to say about OVN this week, did some reviews. Posted a fix for the classifier crash in OVS caused by configuration of prefixes from OVN side.

16:19 <imaximets> That's all from me.

16:20 <amusil> Hi

16:20 <imaximets> Who wants to give an update?

16:20 <_lore_> I can give a quick update

16:20 <imaximets> _lore_, go ahead!

16:21 <_lore_> I was looking at a possible problem of route-exchange codebase

16:21 <_lore_> since fnordahl is here :)

16:21 <fnordahl> shoot away, and I'll see if I can answer

16:21 <_lore_> in particular it seems a keep a state for _maintained_route_tables and _maintained_vrf between route_exchange_run() runs, right?

16:22 <_lore_> this does not take into account possible netlink failures

16:22 <_lore_> if this happens OVN is not aligned to the kernel configuration

16:22 <_lore_> right?

16:23 <_lore_> in particular when we run re_nl_cleanup_routes() and re_nl_delete_vrf()

16:24 <_lore_> in some way we should monitor the operation results to see if we need to retry the configuration during next iteration

16:24 <_lore_> fnordahl: agree?

16:24 <_lore_> that's all from my side

16:25 <fnordahl> Sounds reasonable, I would hope it did not get on the maintained list if there was a failure, if it does that sounds like a bug

16:26 <_lore_> fnordahl: what do you mean with 'maintained list'?

16:26 <fnordahl> I was referring to your mention of _maintained_route_tables and _maintained_vrf

16:27 <_lore_> at the beginning of route_exchange_run() we do something like: _maintained_route_table -> old_maintained_route_table

16:28 <_lore_> and then at the end of the route_exchange_run() we get rid of old_maintained_route_table

16:28 <_lore_> so we one of the configuration in old_maintained_route_table is not getting through the kernel, this configuration is lost

16:29 <_lore_> but I guess we can continue the discussion on the ML

16:29 <_lore_> thx

16:29 <imaximets> OK. Thanks, _lore_ !

16:29 <imaximets> Who's next?

16:29 <fnordahl> sure, let's do, thanks _lore_

16:30 <imaximets> fnordahl, do you have some updates this week maybe? :)

16:31 <fnordahl> Back from internal sprints, we have a roadmap and are at the start of our cycle, at a high level mostly downstream integration work for the route-exchange stuff that landed in 25.03, looks like we have a common goal of making use of this with OpenStack so we'll likely work with you on that

16:31 <fnordahl> And from the sound of it there will be bug fixes :)

16:31 <imaximets> fnordahl, nice! :)

16:31 <fnordahl> mj2s multinode test is useful for this work so I'll get my act together and review it.

16:32 <fnordahl> I know mkalcok did some experimentation with a different CMS too, and there are some unanswered questions on what to do with return path, so we'll see if we get downstream to do somethinig there or if we find the time to propose an update to ovn

16:33 <fnordahl> thanks for merge of that s390x-only test fix btw, and I guess that's it for me

16:33 <imaximets> fnordahl, thanks!

16:33 <imaximets> Who wants to go next?

16:33 <amusil> I don't have anything special, I did some maintainer work that's about it for u/s

16:34 <imaximets> Thanks, amusil !

16:34 <mkalcok> NOthing much from my side either, lot's of downstream work.

16:34 <amusil> fnordahl Just a quick Q, do you plan to revive the patch about inactivity probes in tests?

16:36 <fnordahl> amusil: it did show up as an issue in Debian CI, so it will likely resurface if we don't. The "makes tests fail more often" facet of this is a bit untangable though, nothing stood out as obvious the last I looked. I'll put it on the list of things to do

16:37 <amusil> Ack, thanks!

16:37 <imaximets> OK. Last call for anyone who wants to share! :)

16:37 <zhouhan> I have an quick update for the HW offload issue and the ct-commit-all. I sent an email explaining the new issues we were facing and the challenges of the ct-commit-all approach, and got agreement with Dumitru and Tim that we will move forward with the simpler solution just avoiding conflict port ranges. Tim already sent ovn-k8s PR for this, and I

16:37 <zhouhan> will send patches to revert the problematic patch in OVN.

16:37 <zhouhan> that's it from me

16:38 <imaximets> Thanks, zhouhan !

16:38 <amusil> zhouhan In regards to that, we probably want to pursue the zone split that Dumitru suggested

16:39 <amusil> Because ct-commit-all is needed for L2 UDN in local gateway mode

16:39 <zhouhan> amusil: In theory that may work, but I am not sure if it worth the effort and complexity, if we can simply avoid port conficts

16:40 <amusil> It depends if ovnk is able to find different solution for L2 UDN, if not we might need it otherwise it wouldn't work with HWOL

16:40 <zhouhan> amusil: I didn't mean we should revert the whole ct-commit-all, but just need to revert the part that was particularly made for the HWOL issue (some comments I had given to you for one of the revisions, if you remember :))

16:41 <amusil> Well let's discuss over the patch because I'm not sure if there are parts that could be reverted specifically, but I might be wrong

16:42 <imaximets> Less workarounds the better. :)

16:42 <imaximets> OK. I gess, that's everyone I saw joining today.

16:42 <imaximets> Thanks! And see you next week!

16:42 <mkalcok> o/

16:42 <imaximets> Bye.

16:42 <zhouhan> amusil: ok, I will double check the test case for L2 UDN, and discuss in the ML

16:42 <zhouhan> Thanks, bye!

16:43 <fnordahl> \o cheers!

16:43 <amusil> Ack, thanks! Bye

16:43 <_lore_> bye