14:10:19 <haleyb> #startmeeting networking-ovn
14:10:20 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:10:23 <openstack> The meeting name has been set to 'networking_ovn'
14:10:28 <haleyb> #chair tidwellr
14:10:30 <openstack> Current chairs: haleyb tidwellr
14:10:58 <haleyb> #topic Announcements
14:11:35 <haleyb> First announcement is it's been too long between meetings, my fault for taking summer vacations
14:12:15 <tidwellr> it was a busy summer for me too, not much productivity for me
14:12:31 <haleyb> Second is I changed this meeting to bi-weekly from quad-weekly, to make sure we get some planning done
14:13:04 <tidwellr> +1 especially with the PTG coming up
14:13:11 <haleyb> There is a discussion topic on this for the PTG as well, https://etherpad.openstack.org/p/neutron-shanghai-forum-brainstorming
14:14:02 <haleyb> hopefully we can loop you in remotely somehow
14:15:01 <haleyb> that's all i had for announcements
14:15:20 <tidwellr> mlavalle and liuyulong were experimenting with some options, I don't know they have any results yet
14:16:38 <haleyb> options for convergence?
14:17:06 * haleyb switches topics
14:17:09 <tidwellr> remote options for people who can't attend the PTG in person
14:17:16 <haleyb> ah, yes
14:17:58 <haleyb> time difference will be an issue of course
14:18:33 <haleyb> #topic ML2-OVS-DVR/OVN convergence
14:19:19 <haleyb> tidwellr: thanks for updating the spec, i agree with your addition of moving the networking-ovn code into the neutron tree
14:20:34 <tidwellr> 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 <haleyb> yes, agreed
14:22:03 <tidwellr> 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 <haleyb> 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 <tidwellr> I've lost track of where we're at with feature gap analysis in the spec, is that complete?
14:26:48 <haleyb> we might have closed the gap by one item, was just looking.  ICMP frag needed is now supported
14:27:03 <tidwellr> \o/
14:28:14 <haleyb> One of the things we discuss in the spec is what to do about extensions, for example, dvr and ha
14:28:31 <tidwellr> yes
14:29:03 <haleyb> i had started playing with a hack, having the ovn code fake support for router options
14:29:59 <tidwellr> read-only support? or does it go deeper?
14:30:31 <haleyb> 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 <haleyb> tidwellr: the hack was just always setting 'distributed' and 'ha' to True in the router object and DB
14:31:47 <haleyb> it isn't working yet, but things like this are admin-only options anyways
14:31:54 <tidwellr> 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 <haleyb> https://review.opendev.org/#/c/680749/
14:33:05 <haleyb> it was something i started looking at based on https://review.opendev.org/#/c/670291/
14:34:27 <tidwellr> those test results are instructive....
14:34:40 <tidwellr> very nice
14:37:01 <haleyb> 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 <haleyb> that was what i started poking at
14:37:55 <haleyb> or maybe the test doesn't matter any more w/ovn in some cases
14:39:41 <tidwellr> 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 <tidwellr> not sure if that came through clearly, so I'll re-spin the spec
14:40:51 <haleyb> tidwellr: right, and i maybe missed that
14:41:54 <haleyb> i'll add a comment too
14:43:57 <haleyb> tidwellr: and i think after another update we should get that spec merged and move forward with the work
14:44:30 <tidwellr> agreed, I'm biased but I am also happy with where it's at
14:46:52 <haleyb> 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 <haleyb> tidwellr: so did you want to update the patch?
14:50:11 <tidwellr> yes, I'll give it one more spin and it should be ready to go
14:50:27 <haleyb> great, thanks
14:51:56 <haleyb> 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 <tidwellr> yeah, I hope this is a forum topic in Shanghai
14:52:55 <tidwellr> to me this has the biggest potential for impact on operators of all the topics proposed
14:55:22 <haleyb> tidwellr: yes, both the upgrade impact and new tech (if they are changing drivers)
14:56:24 <haleyb> but it should remove the pain point of processing at scale, for example an l3-agent restart takes too long today
14:59:00 <haleyb> we're out of time
14:59:53 <haleyb> 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 <haleyb> #endmeeting