14:02:20 #startmeeting networking-ovn 14:02:21 Meeting started Tue Oct 1 14:02:20 2019 UTC and is due to finish in 60 minutes. The chair is haleyb. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:02:22 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:02:25 The meeting name has been set to 'networking_ovn' 14:02:47 o/ 14:02:55 this time I had it correctly set in my agenda :) 14:02:57 bcafarel: hi 14:03:06 #chair tidwellr 14:03:07 Current chairs: haleyb tidwellr 14:03:50 i need to send a reminder to the ML about this meeting... 14:05:29 bcafarel: i guess it's just the two of us, i'll wait a few minutes for quorum of 3 14:05:45 :) 14:06:46 hi 14:07:06 tidwellr: hi, you make quorum 14:07:08 sorry, had some drama dropping a kid off at school today :( 14:07:35 been there before 14:07:51 comes with the territory 14:08:10 #topic Announcements 14:09:30 I'll just restate their is a discussion topic on this at the PTG, https://etherpad.openstack.org/p/neutron-shanghai-forum-brainstorming 14:10:07 Can add any questions there 14:10:21 these sessions aren't recorded, are they? 14:10:33 no, i don't believe so 14:10:41 didn't think so... 14:11:17 o/ 14:11:26 any other announcements? 14:11:42 we can try to record/broadcast, but the quality will be "guy recording from his laptop in a corner of the noisy room" 14:11:55 :) 14:13:14 #topic ML2-OVS-DVR/OVN convergence 14:13:17 https://review.opendev.org/#/c/658414 14:13:51 There were some comments in the draft last week regarding moving the networking-ovn code into the neutron tree 14:14:39 * haleyb doesn't see jlibosva on freenode 14:15:43 I see him in #openstack-neutron 14:17:16 o/ 14:17:41 from what i understand, if we plan on in the future having OVN as the default, having it in-tree is a requirement, unless i mis-understand things 14:18:11 jlibosva: hi, you're multi-meeting-plexing like me :-/ 14:18:34 just wanted to discuss your comments in the spec 14:18:35 haleyb: :) yeah, using ears in videomeeting and fingers here 14:18:42 hi, sorry for being late 14:18:58 and if I understand jlibosva correctly the concern is really a matter timing for moving things in-tree, am I understanding you correctly? 14:19:06 haleyb: I was not aware of such policy - do you have a link handy where it's defined we need to use in-tree code for default backends? 14:20:28 my point was that we might be taking a big task that might not be necessary - but I was not aware there is a policy that requires the code to be in-tree 14:20:32 jlibosva: i don't have a link to any policy, i just assumed 14:21:23 haleyb: I was under the same assumption, but that's just tribal knowledge I've been handed 14:21:25 it makes it look more supported if it's in-tree 14:22:02 who should have such piece of information? TC members? 14:22:03 * haleyb has been here for a while, but doesn't know for sure 14:22:36 I guess that nobody every raised such question yet in fact :) 14:22:50 Policy requiring code to be in-tree? With my TC member hat on, I think that is up to the projects. 14:23:43 njohnston: I planned to reach out to you, you replied before I asked, thanks :) 14:23:45 I mean, neutron could be arranged so ML2 was a separate repo, ML2/OVS was a separate repo from that, etc. But it would raise the barrier for development work considerably because coordinating changes across repos adds complexity and difficulty 14:24:39 my only concern is the barrier to entry, we already have a number of repo's for code to be scattered across 14:25:35 right, and part of the effort is to lower the bar for working on OVN 14:25:54 it may also makes some things harder, if someone will need to add change which will require patches to 2 repos 14:26:20 it is ofcourse doable with Depends-On but it's easier if all is in one repo and one patch :) 14:26:49 and i know jlibosva already mentioned we have this today with neutron-lib/neutron changes... 14:27:02 yes, also if you want to learn how a features works, it's easier if API and reference implementation are in same place :) 14:27:32 My personal opinion is that with a shrinking dev base we want the barrier for entry into neutron to be as low as possible. 14:28:18 njohnston: +1, and to add to that I feel like more repos = more maintenance overhead 14:28:23 My TC opinion is that neutron knows best how to arrange it's repos, there is not a one-size-fits-all solution. 14:28:25 I agree with all said above, that having it in-tree is simpler. I wanted to make sure it's all worth the effort and that we understand what work needs to be done (merging devstack plugins etc.) 14:29:29 and I understand the burden, when working with tripleo and needed to send a patch to 10 repos, I wanted to shoot myself :) 14:29:45 jlibosva: i will need some help on making the list of work items, and please don't shoot yourself :) 14:30:22 jlibosva: I would say if we're only just "exploring" this, then I agree with you about not proceeding. But, if we are indeed serious about the OVN direction then I think for all the reasons that folks have expressed we should move it in-tree 14:31:12 if all the folks are aware of amount of work it requires and agree it's worth having the code in-tree then sure, let's move towards it 14:31:50 we have 30 minutes, so can discuss the work, even if some is obvious, or i can start an etherpad to collect it 14:33:07 jlibosva: if we've resolved your concern about in-tree vs. not, is there anything else that stood out in the spec that you think should be addressed? 14:34:26 perhaps - do we want to have another spec for the move or is everybody ok with what is currently in the spec regarding the move? 14:37:39 crickets... 14:38:51 I'm all right with it 14:38:52 I mentioned this to haleyb before, I don't think another spec is in order. But I'm just one person..... 14:39:14 jlibosva: do you want me to start an etherpad so we can list the work items? then maybe after a little brainstorming we'll have a pretty good list 14:39:22 haleyb: sounds good 14:40:18 and if some "oh shit" item comes up we can work throught it 14:40:23 +1 that could be then summarized/reused in the spec if we realize it is complicated 14:40:25 haleyb: etherpad with todo list sounds good for me 14:41:07 #action haleyb to make an etherpad outlining steps of moving OVN in-tree 14:42:08 +1 14:42:27 +1 14:43:29 i'll do that today and add a link to the spec 14:45:21 is there anything else people want to discuss about the spec? 14:46:56 #topic Open Discussion 14:47:25 What is left before the spec can merge, in your mind haleyb? Do we need to have the work items enumerated? 14:47:30 jlibosva: this is where we talk about deprecating linuxbridge to free-up zuul space :) 14:47:46 haleyb: I added that as a PTG topic 14:48:00 njohnston: i think just adding a link to the etherpad so it's findable 14:48:02 \o/ 14:50:20 njohnston: thanks, i'll go look, it's always a good time to talk about # of jobs 14:51:57 any other topics? 14:53:08 ok, well thanks for coming everyone and having a good discussion 14:53:13 #endmeeting