14:10:19 #startmeeting networking-ovn 14:10:20 Meeting started Tue Sep 17 14:10:19 2019 UTC and is due to finish in 60 minutes. The chair is haleyb. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:10:21 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:10:23 The meeting name has been set to 'networking_ovn' 14:10:28 #chair tidwellr 14:10:30 Current chairs: haleyb tidwellr 14:10:58 #topic Announcements 14:11:35 First announcement is it's been too long between meetings, my fault for taking summer vacations 14:12:15 it was a busy summer for me too, not much productivity for me 14:12:31 Second is I changed this meeting to bi-weekly from quad-weekly, to make sure we get some planning done 14:13:04 +1 especially with the PTG coming up 14:13:11 There is a discussion topic on this for the PTG as well, https://etherpad.openstack.org/p/neutron-shanghai-forum-brainstorming 14:14:02 hopefully we can loop you in remotely somehow 14:15:01 that's all i had for announcements 14:15:20 mlavalle and liuyulong were experimenting with some options, I don't know they have any results yet 14:16:38 options for convergence? 14:17:06 * haleyb switches topics 14:17:09 remote options for people who can't attend the PTG in person 14:17:16 ah, yes 14:17:58 time difference will be an issue of course 14:18:33 #topic ML2-OVS-DVR/OVN convergence 14:19:19 tidwellr: thanks for updating the spec, i agree with your addition of moving the networking-ovn code into the neutron tree 14:20:34 I know networking-ovn is quite an active project and part of the argument for the stadium is to decouple from the main repo, but I think it will evolve faster in the neutron tree 14:22:02 yes, agreed 14:22:03 the barrier to entry for folks like me to start pitching will be lowered too (not that it's that high right now) 14:24:05 yes, hopefully moving it in-tree will make it easier for others to play with, since it should involve making it easier to choose for devstack imo 14:25:51 I've lost track of where we're at with feature gap analysis in the spec, is that complete? 14:26:48 we might have closed the gap by one item, was just looking. ICMP frag needed is now supported 14:27:03 \o/ 14:28:14 One of the things we discuss in the spec is what to do about extensions, for example, dvr and ha 14:28:31 yes 14:29:03 i had started playing with a hack, having the ovn code fake support for router options 14:29:59 read-only support? or does it go deeper? 14:30:31 but dalvarez brought up a point - why are we doing that? maybe it's a good chance to shrink the list of options we need when moving to OVN 14:30:59 tidwellr: the hack was just always setting 'distributed' and 'ha' to True in the router object and DB 14:31:47 it isn't working yet, but things like this are admin-only options anyways 14:31:54 I had the same thought as dalvarez too, we get the equivalent functionality in the data plane without the API extension that is only for admin's anyway 14:32:04 https://review.opendev.org/#/c/680749/ 14:33:05 it was something i started looking at based on https://review.opendev.org/#/c/670291/ 14:34:27 those test results are instructive.... 14:34:40 very nice 14:37:01 yes, it shows the gap pretty well. how best do we not lose test coverage based on an extension not being present? 14:37:08 that was what i started poking at 14:37:55 or maybe the test doesn't matter any more w/ovn in some cases 14:39:41 what I tried to say in the spec is that 1-1 parity for API extensions, etc. is not strictly required as long as there is equivalent functionality when you take a step back 14:40:28 not sure if that came through clearly, so I'll re-spin the spec 14:40:51 tidwellr: right, and i maybe missed that 14:41:54 i'll add a comment too 14:43:57 tidwellr: and i think after another update we should get that spec merged and move forward with the work 14:44:30 agreed, I'm biased but I am also happy with where it's at 14:46:52 because the next step is to write a spec/blueprint on doing the work - eg moving networking-ovn code into the neutron repo 14:49:48 tidwellr: so did you want to update the patch? 14:50:11 yes, I'll give it one more spin and it should be ready to go 14:50:27 great, thanks 14:51:56 so once we merge that we can move forward. one thing is to better publicize our plan, although anyone lurking here can read the spec :) 14:52:20 yeah, I hope this is a forum topic in Shanghai 14:52:55 to me this has the biggest potential for impact on operators of all the topics proposed 14:55:22 tidwellr: yes, both the upgrade impact and new tech (if they are changing drivers) 14:56:24 but it should remove the pain point of processing at scale, for example an l3-agent restart takes too long today 14:59:00 we're out of time 14:59:53 tidwellr: thanks for attending. when we merge spec we'll send an email to the list about it, and mention this meeting again so people add it to their calendars for next time :) 15:00:01 #endmeeting