17:15:34 <mmichelson> #startmeeting ovn-community-development-discussion
17:15:35 <openstack> Meeting started Thu Apr  2 17:15:34 2020 UTC and is due to finish in 60 minutes.  The chair is mmichelson. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:15:36 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:15:38 <openstack> The meeting name has been set to 'ovn_community_development_discussion'
17:15:45 <numans> Hello
17:15:53 <blp> good morning
17:15:57 <dceara> Hi
17:15:58 <mmichelson> Let's do a meeting
17:15:59 <_lore_> hi all
17:16:09 <mmichelson> I can get things started
17:16:24 <blp> mmichelson: Did we do the magic thing with the bot?
17:16:33 <mmichelson> blp, yep, just before you joined
17:16:39 <blp> OK
17:17:08 <mmichelson> I've been firmly in the land of SCTP recently. We got a patch for SCTP load balancer support put into master, and I now have a patch adding a load balancer test case for SCTP
17:17:18 <mmichelson> By "I have a patch" I mean I posted it for review
17:17:40 <mmichelson> Quesetion: what would all of you think about backporting SCTP load balancers to 20.03?
17:18:01 <mmichelson> s/Quesetion/Question/
17:18:05 * blp has never had an SCTP load to balance
17:18:35 <mmichelson> that does not surprise me.
17:19:06 <blp> Well, since no one has offered opinions, I'll offer some questions.
17:19:17 <blp> How big and possibly disruptive is the change?
17:20:15 <mmichelson> blp, it's small. It essentially adds some code to northd that makes it so that "sctp" can be present for load balancer flows in addition to "tcp" and "udp"
17:20:30 <mmichelson> And the presence of a test should make us more confident in its correctness.
17:20:31 <blp> Sounds reasonable to me.
17:20:55 <mmichelson> I also wanted to bring up the CI e-mail I sent this past Friday. Whenever any of you has a chance to have a look at it, please feel free to respond with opinions on it. I'm already basically moving forward with it under the assumption that no response means approval.
17:21:00 <numans> I'm fine with the backport.
17:21:52 <numans> mmichelson, I don't have any comments. Having CI is awesome.
17:22:04 <mmichelson> Anyways, those were the only topics I had wanted to bring up. Whoever wants to go next can feel free.
17:22:10 <blp> It's hard for me to guess why anyone would object, except possibly to the gating part.
17:22:27 <blp> And presumably that would be phased in.
17:23:35 <numans> I can go in next
17:24:22 <numans> I submitted the vtep to ramp patches. First patch is blp's and the second patch renames ovn-controller-vtep to ovn-controller-ramp
17:24:26 <numans> and the related code.
17:25:10 <numans> taoyunupt <taoyunupt@126.com> was testing ovn-controller-vtep. So I asked if he/she can test the patches out.
17:26:00 <numans> I submitted the v2 of I-P patches after dropping the patches 5 and  6 from the series
17:26:18 <numans> As it requires some more work. zhouhan thanks for looking into the patches and providing the feedback
17:26:33 <numans> I've started looking into addressing his comments.
17:26:44 <numans> And I did some code reviews too.
17:26:47 <numans> That's it from me.
17:26:54 <zhouhan> numans: thanks
17:27:21 <dceara> I can go next if that's ok.
17:27:29 <numans> zhouhan, I want to discuss few things. We can discuss probably after  every one is done if you're fine
17:27:44 <numans> dceara, please
17:28:00 <zhouhan> numans: sure
17:28:38 <dceara> regarding the missing SB updates issue I reported a couple of weeks ago, I still couldn't pinpoint the root cause but in the meantime I sent a patch to at least recover ovn-controller when the idl is in inconsistent state: https://patchwork.ozlabs.org/patch/1262361/
17:28:43 <blp> I'm going to drop out for a few minutes for a brief video chat. I don't have anything important to say so if I disappear for the rest of the meeting don't mind me.
17:29:59 <dceara> Also, I started a thread on the discuss ML to see if there are any potential problems with adding per logical switch port metadata that could be used to simplify network policies in CMSs (ovn-kubernetes in this case)
17:31:07 <zhouhan> blp: before you go, there is a patch need your review https://patchwork.ozlabs.org/patch/1264446/
17:31:11 <dceara> And, numans, I have this follow up patch that fixes a potential issue with virtual port bindings for when you have time: https://patchwork.ozlabs.org/patch/1265487/
17:31:21 <numans> dceara, ack.
17:32:16 <dceara> that's it on my side, thanks
17:33:14 <mmichelson> OK we've got a few more people here. who'd like to go next?
17:33:40 <zhouhan> I have no update this week
17:34:15 <mmichelson> ah, ok
17:34:19 <_lore_> can I go next? very quick
17:35:00 <mmichelson> do it!
17:35:15 <_lore_> this week I posted v9 of IPv6 prefix delegation series addressing Numan's comment on v8 and I worked little bit downstream backporting upstream fixes
17:35:40 <_lore_> now I am trying to understand if we can simplify arp stage in router pipeline
17:36:05 <_lore_> and I forgot, I updated the ovn-scale-test pr with Numan's comments
17:36:17 <_lore_> that's all from me
17:36:33 <mmichelson> OK, anybody else?
17:36:56 <flaviof> I have no update this week, sorry
17:37:09 <numans> I have a few questions to zhouhan if no one else has any updates
17:38:27 <numans> zhouhan, regarding the runtime data changes, I think it makes sense if the runtime data provides the input of "what changed" to flow output engine in order for it to handle  the changes incrementally
17:39:15 <zhouhan> yes, that is needed if we want to I-P it
17:39:23 <numans> So I'm planning to proceed on this direction . i.e runtime data will provide information like - this port bound, this port unbound, this datapath got deleted etc
17:39:42 <numans> zhouhan, I wanted to check with you if this is fine ?
17:39:48 <numans> and looks like you're :)
17:40:01 <zhouhan> yes, I think that's the only way :)
17:40:19 <numans> zhouhan, indeed.
17:40:23 <zhouhan> But I do think it is better to split into different nodes
17:40:32 <numans> zhouhan, ok. like ?
17:40:49 <zhouhan> It would be hard to try to handle all changes incrementally in one shot
17:40:55 <numans> zhouhan, right now we store 2 main imformation in runtime data -
17:41:01 <numans> 1. binding related
17:41:05 <numans> 2. active tunnels
17:41:25 <numans> I'll see if that's possible.
17:41:43 <blp> OK I'm back.
17:42:12 <numans> zhouhan, I also think if we handle runtime data changes in flow output, then probably there is no need to handle port binding changes in flow output.
17:42:23 <numans> zhouhan, any comments there ?
17:42:37 <blp> zhouhan: That patch looks straightforward. I was worried about it until you mentioned that there's already the heartbeat.
17:42:37 <zhouhan> For the rest of the data in runtime_data, if there is no plan to I-P it for now, we can leave them in runtime data, and split the other ones (that can be I-Ped) into new nodes, which would be more clear (and easier to implement, I think)
17:42:38 <numans> blp, I think we are almost done. I had few questions for zhouhan at the end.
17:43:11 <blp> I have a short update when everyone else is done.
17:43:24 <zhouhan> blp: so do you think it is safe to merge?
17:43:33 <blp> zhouhan: yes, I'll take care of it.
17:43:41 <zhouhan> thanks blp
17:44:02 <numans> zhouhan, ok. Thanks for the comments. I'm done
17:44:09 <mmichelson> blp, I think you can give your update if you'd like.
17:44:44 <blp> OK, my update is that I'm moving forward in porting patches to the ddlog version of northd.
17:45:05 <blp> Currently I'm working on service monitors. They're tricky.
17:45:30 <blp> I have to say that the hardest part of it is usually figuring out what the existing code in ovn-northd.c is doing and what its intent is.
17:45:46 <blp> And quite often hundreds of lines of C code end up as a dozen lines of DDlog.
17:46:00 <zhouhan> Awesome
17:46:02 <numans> that's awesome.
17:46:18 <numans> Hope it's not hard for new comers :(
17:46:19 <numans> :)
17:46:26 <numans> I meant this -> :)
17:46:33 <blp> It's a little frustrating looking at the dates in the commits, because  it seems like about 90% of OVN was committed in November.
17:46:39 <blp> I'm not quite sure how that happens.
17:47:01 <blp> I think I should be able to write up an introduction that helps a lot with understanding it.
17:47:26 <blp> Datalog looks really opaque at first, but I've devised some strategies for reading it and writing it that make it much easier for me.
17:47:46 <numans> blp, are those patches pre split ?
17:48:25 <flaviof> blp how about an episode in ovs orbit on this topic?
17:48:28 <blp> No, this is post-split I think.
17:48:36 <numans> oh ok.
17:48:51 <blp> I should start doing OVS Orbit again.
17:48:58 <flaviof> +1
17:49:09 <numans> that's a good idea and may be with leonid
17:49:12 <blp> I'd want to find someone to talk to about it. Maybe Leonid.
17:49:22 <numans> +1
17:49:25 <blp> I hate trying to do episodes where I just talk by myself.
17:49:27 <zhouhan> I stopped listen to anything since the stay-at-home ...
17:49:51 <blp> zhouhan: That's the other thing! I'm not listening to podcasts much because I mostly do that on my bike (or in the car) and I'm not commuting anymore.
17:50:10 <blp> although for some reason I'm in the habit of listening when I'm cooking, so I do still listen a little.
17:50:13 <blp> Anyhow, I'm done.
17:50:25 <dceara> blp, I gave it a try on our scale test infra with a rebased version of the ddlog-dev-v2 branch and at least in our scenario I saw some performance impact and quite a lot of high CPU from ovn-northd-ddlog which was quite surprising as I expected updates to be incremental. I didn't dig too much into it but I plan to. Might be related to the specific scenario we test.
17:50:45 <blp> Updates should be incremental.
17:51:12 <blp> I'm sure there will be some optimization work. Currently I'm writing everything in the most obvious way, but some profiling is needed.
17:52:05 <dceara> blp, ack, if you need scale testing feel free to reach out. We're planning to upstream all the test work but we're not there yet..
17:52:27 <blp> dceara: The "replay" feature should make it easy to try to optimize specific cases, once we're to that point.
17:54:04 <numans> I've to sign off.
17:54:09 <numans> Bye
17:54:12 <dceara> blp, right, I'll dig more into it coming weeks
17:54:27 <mmichelson> If there's nothing else, then I guess we can end this.
17:54:32 <blp> mmichelson: +1
17:54:48 <mmichelson> Okie-dokie. Have a good evening and a good weekend. Stay safe!
17:54:50 <mmichelson> #endmeeting