14:02:20 <haleyb> #startmeeting networking-ovn
14:02:21 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:02:25 <openstack> The meeting name has been set to 'networking_ovn'
14:02:47 <bcafarel> o/
14:02:55 <bcafarel> this time I had it correctly set in my agenda :)
14:02:57 <haleyb> bcafarel: hi
14:03:06 <haleyb> #chair tidwellr
14:03:07 <openstack> Current chairs: haleyb tidwellr
14:03:50 <haleyb> i need to send a reminder to the ML about this meeting...
14:05:29 <haleyb> bcafarel: i guess it's just the two of us, i'll wait a few minutes for quorum of 3
14:05:45 <bcafarel> :)
14:06:46 <tidwellr> hi
14:07:06 <haleyb> tidwellr: hi, you make quorum
14:07:08 <tidwellr> sorry, had some drama dropping a kid off at school today :(
14:07:35 <haleyb> been there before
14:07:51 <tidwellr> comes with the territory
14:08:10 <haleyb> #topic Announcements
14:09:30 <haleyb> 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 <haleyb> Can add any questions there
14:10:21 <tidwellr> these sessions aren't recorded, are they?
14:10:33 <haleyb> no, i don't believe so
14:10:41 <tidwellr> didn't think so...
14:11:17 <njohnston> o/
14:11:26 <haleyb> any other announcements?
14:11:42 <bcafarel> 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 <tidwellr> :)
14:13:14 <haleyb> #topic ML2-OVS-DVR/OVN convergence
14:13:17 <haleyb> https://review.opendev.org/#/c/658414
14:13:51 <haleyb> 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 <bcafarel> I see him in #openstack-neutron
14:17:16 <jlibosva> o/
14:17:41 <haleyb> 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 <haleyb> jlibosva: hi, you're multi-meeting-plexing like me :-/
14:18:34 <haleyb> just wanted to discuss your comments in the spec
14:18:35 <jlibosva> haleyb: :) yeah, using ears in videomeeting and fingers here
14:18:42 <slaweq> hi, sorry for being late
14:18:58 <tidwellr> 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 <jlibosva> 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 <jlibosva> 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 <haleyb> jlibosva: i don't have a link to any policy, i just assumed
14:21:23 <tidwellr> haleyb: I was under the same assumption, but that's just tribal knowledge I've been handed
14:21:25 <haleyb> it makes it look more supported if it's in-tree
14:22:02 <jlibosva> 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 <slaweq> I guess that nobody every raised such question yet in fact :)
14:22:50 <njohnston> Policy requiring code to be in-tree?  With my TC member hat on, I think that is up to the projects.
14:23:43 <jlibosva> njohnston: I planned to reach out to you, you replied before I asked, thanks :)
14:23:45 <njohnston> 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 <tidwellr> 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 <haleyb> right, and part of the effort is to lower the bar for working on OVN
14:25:54 <slaweq> it may also makes some things harder, if someone will need to add change which will require patches to 2 repos
14:26:20 <slaweq> it is ofcourse doable with Depends-On but it's easier if all is in one repo and one patch :)
14:26:49 <haleyb> and i know jlibosva already mentioned we have this today with neutron-lib/neutron changes...
14:27:02 <bcafarel> 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 <njohnston> 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 <tidwellr> njohnston: +1, and to add to that I feel like more repos = more maintenance overhead
14:28:23 <njohnston> 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 <jlibosva> 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 <jlibosva> 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 <haleyb> jlibosva: i will need some help on making the list of work items, and please don't shoot yourself :)
14:30:22 <tidwellr> 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 <jlibosva> 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 <haleyb> 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 <tidwellr> 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 <jlibosva> 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 <haleyb> crickets...
14:38:51 <njohnston> I'm all right with it
14:38:52 <tidwellr> I mentioned this to haleyb before, I don't think another spec is in order. But I'm just one person.....
14:39:14 <haleyb> 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 <jlibosva> haleyb: sounds good
14:40:18 <haleyb> and if some "oh shit" item comes up we can work throught it
14:40:23 <bcafarel> +1 that could be then summarized/reused in the spec if we realize it is complicated
14:40:25 <slaweq> haleyb: etherpad with todo list sounds good for me
14:41:07 <haleyb> #action haleyb to make an etherpad outlining steps of moving OVN in-tree
14:42:08 <tidwellr> +1
14:42:27 <njohnston> +1
14:43:29 <haleyb> i'll do that today and add a link to the spec
14:45:21 <haleyb> is there anything else people want to discuss about the spec?
14:46:56 <haleyb> #topic Open Discussion
14:47:25 <njohnston> What is left before the spec can merge, in your mind haleyb?  Do we need to have the work items enumerated?
14:47:30 <haleyb> jlibosva: this is where we talk about deprecating linuxbridge to free-up zuul space :)
14:47:46 <njohnston> haleyb: I added that as a PTG topic
14:48:00 <haleyb> njohnston: i think just adding a link to the etherpad so it's findable
14:48:02 <jlibosva> \o/
14:50:20 <haleyb> njohnston: thanks, i'll go look, it's always a good time to talk about # of jobs
14:51:57 <haleyb> any other topics?
14:53:08 <haleyb> ok, well thanks for coming everyone and having a good discussion
14:53:13 <haleyb> #endmeeting