14:00:03 <mlavalle> #startmeeting neutron_drivers
14:00:04 <openstack> Meeting started Fri May 24 14:00:03 2019 UTC and is due to finish in 60 minutes.  The chair is mlavalle. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:05 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:07 <openstack> The meeting name has been set to 'neutron_drivers'
14:00:18 <slaweq> hi
14:00:28 <tidwellr> hi
14:00:54 <mlavalle> hi there
14:01:36 <mlavalle> let's wait a couple of minutes to get quorum
14:01:38 <davidsha> hey
14:02:24 <njohnston> bcafarel: Can you give me the link to the most current version of the OSP 15 issues spreadsheet?o/
14:02:35 <njohnston> oops wrong channel! :-/
14:02:56 <bcafarel> :)
14:03:18 <slaweq> njohnston: You are thinking about OSP-15 all the time :D
14:03:39 <njohnston> :-D
14:04:12 <mlavalle> tidwellr: I think we were not supposed to read that. so erase it from your memory
14:04:22 <mlavalle> :-)
14:04:27 <tidwellr> I see nothing.......
14:04:33 <slaweq> watch out at home, You can say to Your wife "can You give me link to OSP-15 spreedsheet" instead of "can You give me a salt" :D
14:04:45 <njohnston> ROTFL
14:06:08 <ralonsoh> sorry I'm late
14:06:26 <mlavalle> no problem. waiting for quorum
14:06:32 <mlavalle> we need one more driver
14:07:15 <slaweq> I think that amotoki should be around, he was reviewing some patches just few minutes ago :)
14:07:34 <mlavalle> amotoki: ping
14:14:18 * haleyb wanders in late
14:14:31 <mlavalle> welcome haleyb
14:14:41 <haleyb> sorry, was at vet with a very excited dog
14:14:56 <haleyb> the vet gives lots of cookies
14:15:18 <mlavalle> oh, I thought you went late to bed watching the Bruins
14:15:35 <haleyb> not until the 27th, it feels like next season
14:15:48 <slaweq> haleyb: cookies were for You or for the dog? :D
14:16:00 <haleyb> the dog ate enough for both of us :)
14:16:06 <mlavalle> LOL
14:16:06 <slaweq> LOL
14:16:12 <mlavalle> ok, let's get going
14:16:47 <mlavalle> #topic RFEs
14:16:57 <mlavalle> We have one RFE to discuss today
14:16:59 <mlavalle> https://bugs.launchpad.net/neutron/+bug/1828607
14:17:00 <openstack> Launchpad bug 1828607 in neutron "[RFE] DVR Enhancements" [Wishlist,In progress]
14:17:16 <mlavalle> which was submitted by tidwellr
14:18:13 <tidwellr> so, we talked about this at the PTG. This an admittedly lame attempt at starting the ball rolling, there are probably smaller RFE's that fall out of this
14:18:41 <amotoki> hi, sorry for late..
14:18:49 <mlavalle> welcome amotoki
14:19:15 <slaweq> hi
14:19:43 <slaweq> tidwellr: IMHO each point from "proposed changes" in Your spec can be separate RFE
14:20:00 <tidwellr> slaweq: I think so too
14:20:16 <mlavalle> this seems to me more of a "directional RFE"
14:20:35 <mlavalle> what I mean by that is this is going to take us several cycles to implement
14:20:51 <mlavalle> in any case, we would be agreeing to go in a certain direction
14:20:54 <mlavalle> right?
14:21:20 <slaweq> IMO yes
14:21:24 <amotoki> mlavalle: totally agree.
14:21:40 <njohnston> mlavalle: definitely
14:21:44 <tidwellr> I would think so, doing openflow DVR completely and the related OVN topic will take time to evolve
14:21:46 <haleyb> tidwellr: i've been meaning to talk to you about the spec, since some exists already in OVN, and maybe the answer could be to move more in that direction?
14:21:54 <mlavalle> and then probably spawn several individual efforts
14:22:18 <mlavalle> haleyb: yes, that is really my next question
14:22:33 <tidwellr> haleyb: that was a PTG topic, and yes I'm in agreement that we explore how to "meet in the middle"
14:22:47 <mlavalle> I think since this is more of a directional think, we need to ponder how this play with the convergence with OVN
14:23:21 <tidwellr> I've been talking with mlavalle about this, and I think the OVN convergence is very closely related to this proposal
14:24:01 <haleyb> i just don't want to spend time doing something twice if we don't have to, but identifying what we need/want is the first step
14:24:28 <tidwellr> haleyb: I agree, I don't want to re-invent the wheel
14:24:30 <mlavalle> haleyb: out of the features list in the RFE, what is already available in OVN?
14:24:52 <haleyb> distributed dhcp is, let me look
14:25:07 <haleyb> openflow dvr of course
14:25:31 <haleyb> ipv6 is WIP
14:26:04 <tidwellr> it's my understanding that it lacks the fully distributed north-south (AKA fast-exit)
14:26:24 <mlavalle> you mean openflow dvr?
14:26:31 <tidwellr> no, OVN
14:26:49 <haleyb> tidwellr: right, there is no ipv6 fast-exit
14:26:57 <tidwellr> what about IPv4?
14:27:28 <tidwellr> can your route IPv4 directly to the compute node, bypassing a central node?
14:28:01 <haleyb> it does have it for ipv4, it just doesn't have to be on the local compute, it can be on one of many
14:28:47 <haleyb> it's essentially dvr+ha, but the n/s lives on some number of nodes, and can fail-over
14:29:23 <tidwellr> but not on every compute node?
14:30:06 <haleyb> it can be, it's just not required.  i'm probably not explaining it well
14:30:28 <tidwellr> we can chat offline in more detail
14:30:43 <mlavalle> we don't have any other RFE today
14:30:53 <njohnston> haleyb: would it be accurate to say it's like having most or all computes function like distributed network nodes, so traffic might ingres/egress with a different compute from where the instance is
14:30:59 <mlavalle> so we might as well spend some time exploring this today
14:31:28 <haleyb> njohnston: right, it will ingress/egress via a "local" compute node
14:32:16 <tidwellr> with DVR today, I can turn on BGP and expose fixed IP's directly to the fabric and traffic goes directly to the appropriate compute node
14:32:59 <tidwellr> if there were a BGP driver for OVN, is that possible given the state of networking-ovn today?
14:33:59 <haleyb> tidwellr: right.  i'm not sure there's a 1:1 for that, but i could look into it, might even have a doc explaining it better
14:34:37 <haleyb> tidwellr: of course there's nothing stopping people from running the agent on every compute node
14:35:00 * haleyb is still an ovn newbie
14:35:18 <tidwellr> sure, my question is more around whether networking-ovn has the smarts to build the environment in that way
14:35:40 * tidwellr is a newbie too
14:35:50 <mlavalle> well, it has haleyb .... ;-)
14:35:52 <haleyb> i think it does, and bgp is definitely on the list of things we're looking at
14:36:30 <mlavalle> let me make an attempt to porpose a next step.....
14:37:28 <mlavalle> 1) we approve this rfe as a general direction of where we want to go, with reference impelementation, ovn or a combination of both
14:38:01 <mlavalle> 2) tidwellr spells out in the associated spec his complete vision, including the BGP bits
14:38:55 <mlavalle> 3) From there we decide the gaps in the the reference implementation and OVN and make a plan, based on it, on how to meet in the middle
14:40:09 <slaweq> +1, sounds like a good plan for me :)
14:40:31 <mlavalle> This way we force everybody to get more familiar with OVN
14:40:40 <tidwellr> Sounds good. For me, this is really about 2 things: A) how to rid ourselves of the concept of "network nodes"  B) Take advantage of offloading for L3 functions
14:40:49 <haleyb> i can document the gaps we have between OVN and the reference implementation, since we have a lot of that already
14:41:22 <mlavalle> yes, the offloading piece is really important
14:41:33 <mlavalle> it keeps us looking into the future
14:41:48 <tidwellr> yes, and getting the routing functions pushed into OVS helps the offloading cause
14:42:09 <tidwellr> for me, OVN or not is the "how"
14:42:20 <mlavalle> right
14:42:35 <haleyb> mlavalle: the other thing that would be good to have is performance numbers, because we keep hitting our heads on things like rabbit it seems
14:42:43 <mlavalle> but at the same time, if we keep OVN as a target, it forces us to work on the convergence
14:42:46 <tidwellr> some goes for ridding the world of what I see is the plague of network nodes
14:43:03 <tidwellr> *same
14:43:21 <mlavalle> haleyb: ahhh you raise a very good point
14:43:24 <haleyb> tidwellr: plague, lol
14:43:48 <amotoki> +1 for the next steps. there are several points we need to address. we can clarify the next steps and what need to be addressed. you all goes faster than me :)
14:44:05 <mlavalle> tidwellr: can we add the improvement of the RPC channel as item 3 to you list above ^^^^?
14:44:22 <tidwellr> mlavalle: yes, I forgot to mention that
14:44:38 <mlavalle> item C, rather
14:44:51 <tidwellr> mlavalle: so, is this really our convergence spec taking shape then?
14:45:25 <mlavalle> I say let's see it that way until reality forces us to re-think
14:45:52 <mlavalle> how about that?
14:45:58 <tidwellr> makes sense to me
14:46:49 <mlavalle> if we get this going, the other big piece will be how to handle the non ovs banckends
14:47:19 <mlavalle> and an inventory of features parity gaps
14:47:45 <slaweq> mlavalle: but we already have such gaps, right?
14:47:57 <mlavalle> yes
14:48:04 <mlavalle> we just need to address them
14:48:13 <mlavalle> easy peasy
14:48:17 <slaweq> :) sure
14:48:18 <mlavalle> ;-)
14:48:39 <haleyb> mlavalle: things like linuxbridge should just keep working, right?  i guess i more worry about supporting things like the iptables firewall driver indefinitely and such
14:48:43 <amotoki> are you talking about linuxbridge and other drivers? I think when we talk about DVR we are already talking about ovs-dvr.
14:48:50 <slaweq> in fact if there will be someone interested in closing such gaps, then he will propose solutions :)
14:49:34 <mlavalle> one point for me is that I need to start deploying OVN in my performance testbed
14:50:01 <mlavalle> that way we can make comparisosns on the same platorm
14:50:32 <mlavalle> haleyb: yes, you are probably right. I am just trying to come up with a list of things we need to think thorugh
14:51:47 <tidwellr> amotoki: my understand of this is that we are looking at converging ML2+OVS, everything else would continue to live on
14:52:12 <mlavalle> that's probably right
14:53:29 <amotoki> yeah, i think so. if we talk about other drivers like linuxbridge, it would be a discussion on the future of such impls.
14:53:34 <mlavalle> so I think we have a consensus for the plan
14:53:45 <mlavalle> right?
14:54:24 <slaweq> right :)
14:54:28 <amotoki> +1
14:54:28 <njohnston> +1
14:54:47 <haleyb> mlavalle: right, just saying eventually something in say, linuxbridge will break, and without a champion it will become best-effort, even happens with some of these whiz-bang features we've added recently
14:54:50 <haleyb> +1 btw
14:55:15 <mlavalle> haleyb: good point
14:55:33 * haleyb doesn't mean to pick on linuxbridge, could just as easily be the metering agent :-o
14:55:37 <mlavalle> I will probably talk to GoDaddy about championing LB
14:55:58 <mlavalle> ok guys
14:56:03 <mlavalle> we have a plan
14:56:12 <mlavalle> I am going to capture it in the RFE
14:56:17 <mlavalle> and mark it as approved
14:56:31 <mlavalle> Thanks for attending
14:56:33 <tidwellr> I will work on fleshing out this sad excuse for a spec I have going :)
14:56:47 <mlavalle> and have a nice weekend
14:57:02 <njohnston> thanks, you too!
14:57:03 <mlavalle> tidwellr, haleyb: long weekend for us \o/
14:57:09 <mlavalle> and you too njohnston
14:57:13 <slaweq> lucky You :P
14:57:15 <tidwellr> \o/
14:57:30 <slaweq> have a great long weekend then :)
14:57:39 <amotoki> :)
14:57:40 <mlavalle> #endmeeting