ChanServ changed the topic of #openvswitch to: Open vSwitch, a Linux Foundation Collaborative Project || FAQ: http://docs.openvswitch.org/en/latest/faq/ || OVN meeting Thurs 9:15 am US Pacific || Use ovs-discuss@openvswitch.org for questions if you don't get an answer here. || Channel logs can be found at https://libera.irclog.whitequark.org/openvswitch
egy has quit [Quit: ZNC 1.8.1 - https://znc.in]
egy has joined #openvswitch
kuraudo has joined #openvswitch
kuraudo has quit [Quit: kuraudo]
kuraudo1 has joined #openvswitch
kuraudo has joined #openvswitch
kuraudo1 has quit [Ping timeout: 252 seconds]
elvira has joined #openvswitch
froyo has joined #openvswitch
racosta has joined #openvswitch
FH_thecat has quit [Quit: Leaving]
FH_thecat has joined #openvswitch
froyo_ has joined #openvswitch
froyo has quit [Read error: Connection reset by peer]
racosta has quit [Ping timeout: 248 seconds]
racosta has joined #openvswitch
FH_thecat has quit [Quit: Leaving]
FH_thecat has joined #openvswitch
elvira has quit [Ping timeout: 252 seconds]
dceara has joined #openvswitch
ChmEarl has joined #openvswitch
amusil has joined #openvswitch
zhouhan has joined #openvswitch
<imaximets> Morning. :)
<fnordahl> o/
<dceara> Hi!
<imaximets> I think Mark is away today, so maybe I'll host the OVN meeting.
<dceara> imaximets++
<amusil> Hi
<imaximets> I don't have much from my side, been stuck debugging ipsec for the past two weeks, so who wants to start?
<dceara> I don't have much either so I can go next. :)
<imaximets> dceara, sure.
<dceara> One upstream related thing was that hopefully our CI jobs that run ovn-kubernetes tests might be a bit more stable from now on.
<dceara> ovn-kubernetes folks just merged a backport PR to their release-1.0 branch that should make it less flaky.
<dceara> I'm sure there are more issues but we're planning on addressing those in the future by trying to consolidate the CI effort between the two projects.
<dceara> Another thing I wanted to bring up was a question to fnordahl.
<fnordahl> dceara: go for it
<dceara> Related to the BGP effort, I was wondering if you had some time to outline the tasks you were planning on working on in the next dev cycle.
<dceara> We (Red Hat) will probably want to build on top of that too.
<dceara> That's it on my side, thanks.
<fnordahl> I'll take that as cue for my update :) Mostly here to say hello, my non-update is that I'm in crunch for delivering on downstream roadmap commitments for another week. Will try to put together that doc for coming cycles upstream bgp related work as promised asap.
<_lore_> hi all
<fnordahl> Two weeks after next is planning anway, so that will follow naturally
<dceara> fnordahl, great, thanks!
<fnordahl> But will expedite that specific doc
<fnordahl> That's it fo rme
<imaximets> fnordahl, would be good if you - as a sole decision maker for what is included into Ubuntu kernel :) - checked on OVS fixes that are still not there.
<fnordahl> lol, I saw that pointed ovs-dev subject fly by, I'll look into it
<fnordahl> imaximets: thanks!
<imaximets> :D
<imaximets> fnordahl, thanks!
<imaximets> Who wants to go next?
<_lore_> I can go next
<_lore_> quite fast
<imaximets> _lore_, go ahead!
<_lore_> I have mainly working on ovn sampling issue, posted a fix for it
<_lore_> then I would like to help the bgp effort :) so I will wait for fome feedbacks from fnordahl
<_lore_> that's all from my side
<imaximets> Thnaks, _lore_ !
<imaximets> *thanks
<imaximets> Who's next?
<amusil> I can go quickly
<imaximets> amusil, sure
<amusil> I spent most of the time looking through the commit all for LR, it would be nice to get some feedback on the RFC https://patchwork.ozlabs.org/project/ovn/patch/20241008101155.331151-3-amusil@redhat.com/
<amusil> zhouhan If you have some time please take a look
<zhouhan> amusil: ack
<amusil> Other than that some smaller things, that's it, thanks
<imaximets> amusil, thanks!
<zhouhan> I can go quickly
<zhouhan> I am working on an RAFT schema upgrade scale issue - the memory spike on the server. Got some pointers from imaximets last week.
<imaximets> zhouhan, go ahead!
<imaximets> ack. Any preliminary results?
<zhouhan> The findings are: 1. the initial update is a reply to client request, so the backpressure doesn't apply 2. the buffer was actually sent to socket, so backpressure is also not easy (if possible at all)
<zhouhan> It seems difficult to implement a ideal solution for this.
<imaximets> Makes sense.
<imaximets> That aligns with what I've seen in the field as well.
<zhouhan> I am currently looking into a workaround to take care of our downstream operation for now, such as adding some naive delay when sending too much data in one loop
<zhouhan> but definitely not something formal
<zhouhan> that's it from me
<zhouhan> (any other suggestions would be very welcome)
<imaximets> OK. I'll try to think about this on the background. But yeah, it's not a simple issue.
<imaximets> Thanks, zhouhan !
<imaximets> Anyone else here wants to share?
<imaximets> I'll take silence as a 'no'.
<imaximets> Have a nice rest of your day, everyone!
<fnordahl> \o cheers!
<imaximets> Bye!
<dceara> Thanks, bye!
<zhouhan> thanks, bye!
<_lore_> bye
dceara has quit [Quit: Leaving]
<amusil> Thanks, bye
amusil has quit [Ping timeout: 256 seconds]
kuraudo has quit [Remote host closed the connection]
zhouhan has quit [Ping timeout: 256 seconds]
froyo_ has quit [Ping timeout: 264 seconds]
ihrachys has quit [Ping timeout: 265 seconds]
froyo_ has joined #openvswitch
ihrachys has joined #openvswitch
racosta has quit [Remote host closed the connection]
racosta has joined #openvswitch
racosta has quit [Remote host closed the connection]
racosta has joined #openvswitch
_lore_ has quit [Ping timeout: 264 seconds]
_lore_ has joined #openvswitch
racosta has quit [Ping timeout: 245 seconds]
ihrachys has quit [Ping timeout: 245 seconds]
ihrachys has joined #openvswitch