luisfdez has quit [Read error: Connection reset by peer]
mestery3 has joined #openvswitch
luisfdez has joined #openvswitch
nicolasbock has quit [Ping timeout: 248 seconds]
Southparkfan has quit [Ping timeout: 272 seconds]
nicolasbock has joined #openvswitch
erig has quit [Ping timeout: 246 seconds]
unixpro1970 has quit [Ping timeout: 246 seconds]
mestery has quit [Ping timeout: 248 seconds]
mestery3 is now known as mestery
Southparkfan has joined #openvswitch
unixpro1970 has joined #openvswitch
erig has joined #openvswitch
froyo_ has joined #openvswitch
froyo_ has quit [Remote host closed the connection]
ChmEarl has quit [Quit: Leaving]
kuraudo has joined #openvswitch
elvira1 has joined #openvswitch
kuraudo has quit [Remote host closed the connection]
kuraudo has joined #openvswitch
vlrpl has joined #openvswitch
Bossi has quit [Quit: No Ping reply in 180 seconds.]
Bossi has joined #openvswitch
GNUmoon has joined #openvswitch
mtomaska__ has joined #openvswitch
mtomaska_ has quit [Ping timeout: 244 seconds]
tpires_ has joined #openvswitch
elvira1 has quit [Ping timeout: 252 seconds]
elvira has joined #openvswitch
elvira has quit [Ping timeout: 252 seconds]
elvira has joined #openvswitch
unixpro1970 has quit [Ping timeout: 244 seconds]
unixpro1970 has joined #openvswitch
elvira has quit [Ping timeout: 248 seconds]
ihrachys2 has quit [Quit: WeeChat 4.4.3]
dceara has joined #openvswitch
amorenoz has quit [Ping timeout: 255 seconds]
ArtGravity has joined #openvswitch
ChmEarl has joined #openvswitch
mj2 has joined #openvswitch
<mj2>
hello!
zhouhan has joined #openvswitch
<felixhuettner>
hi everyone
<zhouhan>
hi
<_lore_>
hi all
mkalcok has joined #openvswitch
<mkalcok>
o/
<mj2>
hi martin!
<fnordahl>
o/
<mj2>
hi frode!
<imaximets>
Hello there.
<imaximets>
Mark is off today again. So, I guess, I'll be hosting today.
<imaximets>
Let's start the OVN weekly meeting.
<imaximets>
I can start with a small update.
<imaximets>
Not much OVN-related this week, but I posted a patch to deprecate STT tunnels support in OVN.
<imaximets>
This is following the same thing in OVS.
<imaximets>
Support for STT in OVS will be removed in 3.6.
<imaximets>
A quick reminder for everyone that we have not a lot of time left until the OVS soft freeze and OVN afterwards, so try to get your patches posted. :)
<imaximets>
That's all I have.
<imaximets>
Who wants to go next?
<fnordahl>
I have an update
<mkalcok>
I have a quick update if I may
<mkalcok>
damn
<fnordahl>
mkalcok: go ahead
<mkalcok>
frode, go ahead
<imaximets>
:)
<fnordahl>
lol
<imaximets>
fnordahl, go ahead!
<fnordahl>
Prepared openvswitch 3.5 snapshot built against DPDK 24.11 for development version of Debian/Ubuntu, hit a link-level change of behavior as in programs linked consuming more memory breaking tests. Worked around i
<fnordahl>
t for now.
<fnordahl>
Other than that I've been working on a respin of the OVS route-table changes, will hopefully post a series tomorrow.
<fnordahl>
That's it for me.
<imaximets>
Thanks, fnordahl ! Eelco is waiting for those patches. :)
<imaximets>
Hopefuly we can get them reviewed quickly once posted.
<fnordahl>
cool, thanks imaximets !
<imaximets>
mkalcok, your turn.
<mkalcok>
thanks
<mkalcok>
I posted iteration on Felix's work to enable IPv4 routes with IPv6 prefixes. v7 was mainly about adding more tests and reordering of the patch
<mj2>
that reasoning is mentioned in a couple places
<dceara>
I'll try to have a closer look tomorrow to see if we can change this.
<mj2>
okay, cool
<imaximets>
Should this be configurable?
<dceara>
I'm not sure, yet. :)
<imaximets>
Sounds like "you set up localnet network, so it's your problem that your router is confused now" :) But IDK, not an expert.
<mj2>
being able to do localonly periodic RAs is quite important to the bgp unnumbered use case
<dceara>
Ack.
<mkalcok>
dceara: I'm curious, wouldn't the same confusion be caused by the RAs to solicitation messages? Because those make it out to localport just fine
<fnordahl>
I seem to remember thinking the router being confused being someone elses problem the last time I saw this discussed too. Thanks for checking!
<imaximets>
OK. I guess, we can follow up on that on the list.
<mj2>
okay, cool
<mkalcok>
+1
<dceara>
I think it's slightly more complex. Possibly due to the E-W routing case with localnet (no encap).
<dceara>
zhouhan, I did hear from Red Hat users (OpenStack and OpenShift) and it should be fine. But I don't know about other CMS use cases.
<zhouhan>
dceara: so from which groups are we waiting?
<zhouhan>
dceara: from my perspective, the old behavior doesn't really make sense and hard to image any users would depend on that behavior. But would be happy to wait if there are more input expected from any other users
<dceara>
Well, we know for sure Vladislav's team uses OVN. I don't know if Nutanix uses policy=src-ip. It's kind of hard.. we can't know exactly who the users are. And while the old behavior seems broken I still feel a bit worried about changing something so old.
<dceara>
However, if we wait a bit longer without getting replies we can document the change and add a NEWS item (already there) and hope for the best. :)
<zhouhan>
sounds good
<zhouhan>
Let me try to ping Vladislav and some Nutanix folks
<dceara>
zhouhan, thanks!
<zhouhan>
Other than this I was working on an internal feature that was broken by OVN-k8s-IC
<zhouhan>
and some small code review. Catching up with community meeting recordings
<zhouhan>
that's it from me
<imaximets>
Thanks, zhouhan !
<imaximets>
Who's next?
<dceara>
I can go next, I guess.
<imaximets>
dceara, sure.
<dceara>
I reviewed some of Felix and Frode's BGP patches (mostly the first part of the series). I also reviewed the first version of the SB schema change for Routes and suggested some small changes. When those are taken care of I'd like to merge it to unblock the rest of the work.
<dceara>
If people don't object.
<dceara>
Aside from that I've been busy with some ovn-k8s work but hope to get back to ovn reviews tomorrow.
<dceara>
That's it on my side.
<dceara>
Oh, one thing I just remembered.
<dceara>
There's an ovn-org slack workspace - it was mostly used by ovn-kubernetes folks but it also has an #ovn channel.
<dceara>
ovn-kubernetes is moving to CNCF so the question is if we want to take over the workspace.
<dceara>
I can try to bring that up on list too though.
<dceara>
That's it from me.
<mkalcok>
is the whole slack instance going away (including the ovn channel)?
<dceara>
That was the initial plan but dceara is a workspace admin (along with other people) so we can take it over if we wish.
<mkalcok>
oh, right
<mkalcok>
got it, thanks
<fnordahl>
initial reaction would be: if I can avoid having another window with interactive messaging in, but I also don't want to be a categoric detractor
<dceara>
fnordahl, :)
<imaximets>
Generally speaking, slack is not that friendly for non-corporate users, or users who don't already have it. FWIW.
<imaximets>
OK.
<imaximets>
Thanks, dceara !
<imaximets>
One more thing I have is I'd like to bring some attention to increased number of recirculations in the router pipeline one more time that Ales is introducing with the "commit all" change.
<imaximets>
IIUC, there will be more recirculations in the datapath for all the traffic.
<imaximets>
From OVS perspective we're concerned about both dataplane performance and potential to hit recursion limits. So, if someone can test those out and get some data that would be great.
<dceara>
imaximets, do I remember correctly that you suggested at some point that we should conntrack everything for correctness? /me hides :)
<zhouhan>
imaximets: I promised to test those. will resume it soon
<dceara>
zhouhan++
<imaximets>
dceara, sure. But I also suggested that OVN should use a signle zone per datapath. :P
<imaximets>
*single
<imaximets>
If there are ideas on how to fix the issues Ales is trying to fix without extra recirculations, that would be great as well.
<zhouhan>
imaximets: there were attempt to combine the zones, but there were also very tricky issues introduced and that got reverted and only used when an option is set explicitely
<fnordahl>
We have users with the kind of desires leading to more conntrack so we'll definitively discuss it
<imaximets>
Yeah. Adding more and more conntrack in separate zones doesn't really scale on a node level. So, we'll have to try and re-use conntrack between entities at some point.
<felixhuettner>
are there more expected recirculations when traffic is going through an LR with all traffic already being natted? or just in mixed use cases?
<imaximets>
I'm not 100% sure. Maybe zhouhan or dceara knows details?
<zhouhan>
It will always have more recirc
<felixhuettner>
so basically +1 recirc for each LR that is traversed?
<zhouhan>
yes, but only when stateful nat/LB is enabled
<felixhuettner>
ok, thanks
<felixhuettner>
then i think i have a case where i could get to 8 recircs, but i would need to check
<imaximets>
OK. Thanks, zhouhan and felixhuettner .
<dceara>
I actually think this problem might be solvable without adding an extra recirculation if we move to a zone per router port. But I didn't think it through properly.
<dceara>
imaximets, more zones, sorry :)
<imaximets>
:)
<imaximets>
OK. Let's continue on a list with this topic as well.
<imaximets>
Anyone else here wants to share?
<imaximets>
Then, I guess, we can call it a meeting.