14:00:50 <mlavalle> #startmeeting neutron_drivers
14:00:51 <openstack> Meeting started Fri Apr  5 14:00:50 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:52 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:54 <openstack> The meeting name has been set to 'neutron_drivers'
14:00:58 <njohnston_> o/
14:01:01 <ralonsoh> hi
14:01:14 <slaweq> hi
14:01:33 <mlavalle> how are y'all?
14:01:47 <amotoki> o/
14:01:47 <mlavalle> haleyb is still on vacation, I beleive
14:01:56 <haleyb> o/
14:02:08 <mlavalle> ahhh, welcome back haleyb
14:02:14 <mlavalle> did you have fun?
14:02:15 <haleyb> i'm back, but in the deep end of the pool
14:02:24 <mlavalle> I bet you missed us all a lot
14:02:27 <haleyb> s/fun/relaxed
14:02:41 <haleyb> getting up late and going to the beach is a lot of work :)
14:02:53 <mlavalle> it is indeed
14:03:05 <haleyb> good to be back though
14:03:12 <slaweq> :)
14:03:14 <mlavalle> let's wait 1 minute
14:04:13 <mlavalle> ok, let's get going
14:04:16 <slaweq> yamamoto just sent an email that he will not be here today
14:04:37 <mlavalle> #topic RFEs
14:04:51 <mlavalle> and we are going to start with https://bugs.launchpad.net/neutron/+bug/1821058
14:04:52 <openstack> Launchpad bug 1821058 in neutron "[RFE] Port binding event extended information for Nova" [Wishlist,Confirmed]
14:05:15 <ralonsoh> I'll ping Sean
14:05:56 <ralonsoh> ok, there are several topics
14:05:59 <ralonsoh> the first one
14:06:07 <ralonsoh> the events into Nova
14:06:16 <mlavalle> There are 3 patches already out there, the most important of which is https://review.openstack.org/#/c/645173/
14:06:40 <ralonsoh> yes, the spec (this is the only one important right now)
14:07:14 <ralonsoh> the main concern, from the Nova side, is why we need those events
14:07:22 <ralonsoh> IMO, we can discuss this in the PTG
14:07:43 <ralonsoh> the second point: driver information
14:08:06 <ralonsoh> in order to know which specific driver are you going to bind the port
14:08:32 <ralonsoh> this will also be needed for #link https://review.openstack.org/#/c/641670/
14:08:51 <ralonsoh> and third, "connectivity"
14:09:10 <mlavalle> well, I think we should strive to come to an agreement as far as the RFE in this meeting
14:09:14 <ralonsoh> to inform about what type of backend we have: legacy (default one), only L2 or L3 (calico)
14:09:37 <amotoki> it looks like that we need to clarify what are needed by this effort.
14:09:43 <mlavalle> and then, with that agreement, you can devlop the spec further, which can be discussed in the PTG
14:10:11 <amotoki> regarding "what type of backend", the question will be how nova can use this information, for example.
14:11:03 <ralonsoh> amotoki, Nova will use this information, for example, in https://review.openstack.org/#/c/641670/
14:11:35 <ralonsoh> amotoki, knowing the driver backend is important to decide if you can or not spawn a VM without IP in the port
14:11:50 <ralonsoh> amotoki, also this is needed for live-migration
14:12:00 <ralonsoh> but Sean knows this information better
14:12:09 <ralonsoh> (I'm still trying to ping him)
14:12:38 <amotoki> ralonsoh: thanks, but I am not sure we should pass a driver information itself or what backend driver(s) support.
14:13:10 <amotoki> (though I need to look through the nova spec)
14:13:15 <ralonsoh> amotoki, at least the name
14:13:17 <njohnston> Is Nova going to be making decisions based on the driver, or just based on characteristics of the driver like backend type?
14:13:29 <njohnston> as expressed in these events
14:13:31 <ralonsoh> amotoki, now we have "ovs" only
14:13:47 <ralonsoh> amotoki, but under this vif_type we have OVS, ODL, OVN, etc
14:14:10 <ralonsoh> amotoki, and the way the ports are bound and the events are different
14:14:49 <ralonsoh> njohnston, Nova should use this information, in live migration, IP-less VMs, etc.
14:14:51 <ralonsoh> hi sean-k-mooney
14:15:01 <amotoki> "driver" information makes sense to me if it is a driver-to-driver communicaiton
14:15:44 <amotoki> it leads to a question how we can generalize information between neutron and nova
14:15:51 <ralonsoh> but, as I said, with vif_type="ovs" we don't really know what bakend we are using
14:16:34 <ralonsoh> sean-k-mooney, what are the problems between ODL, OVS or OVN during live-migration?
14:16:47 <mlavalle> this seems to me as a way to "cope with the ugly reality of the world"
14:17:15 <njohnston> let me put this question another way: does nova need to have code that can differentiate between all drivers?  Would something need to be added to nova to say "if midonet: ..."?
14:18:29 <ralonsoh> njohnston, ok, let me divide the spec in three (those three parameters we need)
14:18:51 <ralonsoh> njohnston, at least, for the IP-less VMs we need to know the connectivity parameter
14:18:58 <ralonsoh> that means, legacy, L2 or L3
14:19:02 <sean-k-mooney> sorry im in another meeting too
14:19:38 <slaweq> ralonsoh: so for connectivity, L3 will mean port with IP address allocated and L2 will mean port without IP, am I right?
14:19:49 <sean-k-mooney> slaweq: no
14:20:06 <sean-k-mooney> l2 means the network backend provide 2 bradcase semantics
14:20:15 <sean-k-mooney> and supprot l2 connecity
14:20:24 <ralonsoh> e.g.: OVS L2, calico L3
14:20:24 <sean-k-mooney> l3 means only ip connectivy is supported
14:20:31 <mlavalle> yeah, the port is in a broadcast domain
14:20:41 <mlavalle> in the case of L2
14:20:44 <sean-k-mooney> yep
14:20:44 <slaweq> ok
14:21:30 <sean-k-mooney> so the reason for not allowing ip_allocaion=none with a l3 only network is that there are no network connecity availble in this case
14:21:43 <mlavalle> right
14:21:45 <sean-k-mooney> e.g. the port is on an l3 only network but has no ip
14:21:57 <mlavalle> it's useless
14:22:30 <slaweq> ok, I see. So if connectivity == L2 then ip_allocation=none will be allowed, right?
14:22:37 <sean-k-mooney> yes
14:22:39 <ralonsoh> exactly
14:22:42 <slaweq> thx
14:23:06 <amotoki> that is understandable but it looks like the meaning should be clarified.
14:23:20 <amotoki> I am not suree what "legacy" means..
14:23:25 <ralonsoh> amotoki, I'll comment this in the spec
14:23:31 <ralonsoh> amotoki, the default value
14:23:40 <ralonsoh> this will be in the abs class
14:23:57 <slaweq> amotoki: from spec "The "legacy" ``connectivity`` value will be the default and
14:23:57 <ralonsoh> of course, I'll review all possible backend projects to add the correct value
14:23:58 <slaweq> is a sentinel to indicate the driver does not support this extension yet and
14:24:00 <slaweq> no connectivity info is available
14:24:06 <ralonsoh> exactly
14:24:35 <mlavalle> I'm curious about the answer to to njohnston's question above^^^^
14:24:52 <mlavalle> can you answer that?
14:25:16 <ralonsoh> mlavalle, right about the drivers
14:26:16 <ralonsoh> sean-k-mooney, correct me if I'm wrong. This information is needed fro live-migration
14:26:32 <sean-k-mooney> sorry which info
14:26:39 <ralonsoh> the driver list
14:26:57 <njohnston> because the differentiation into legacy, l2, and l3 is not sufficient to solve the problem described in lines 52-57 of the spec
14:27:02 <ralonsoh> among with the network events
14:27:05 <sean-k-mooney> no that is need so that we can close a security bug
14:27:30 <mlavalle> in case sean-k-mooney missed it: "does nova need to have code that can differentiate bewteen all drivers? Would something need to be added to nova to say "if midonet:....?"
14:27:32 <sean-k-mooney> it is used so that os-vif can tell if the backend is odl or ml2/ovs in the ovs plugin
14:28:06 <ralonsoh> ^^ #link https://bugs.launchpad.net/neutron/+bug/1734320
14:28:07 <openstack> Launchpad bug 1734320 in OpenStack Compute (nova) "Eavesdropping private traffic" [Undecided,In progress] - Assigned to sean mooney (sean-k-mooney)
14:28:16 <njohnston> but does it need to know about more than just ml2/ovs and odl, does it also need to know which set of characteristics are met by ml2/ovn and midonet and linuxbridge etc.
14:28:18 <sean-k-mooney> nova should not need code for each dirver
14:28:42 <sean-k-mooney> currenly it would be passing it to os-vif for the ovs os-vif puling to use
14:29:17 <sean-k-mooney> nova currently does not no
14:29:22 <slaweq> so You want to tell nova which os-vif driver should be used for port, right?
14:29:23 <mlavalle> but let's extend the question to os-vif. will os vif have networking backend specific code?
14:29:26 <sean-k-mooney> it does need the network events
14:29:50 <sean-k-mooney> but if we use network_events as an abstration we dont need to put code that special cases on backends
14:29:59 <sean-k-mooney> mlavalle: it already does
14:30:14 <mlavalle> ewell yes, you are right
14:30:29 <mlavalle> it already does
14:30:53 <mlavalle> so let me attempt to summarize this:
14:30:54 <ralonsoh> sean-k-mooney, just to clarify: "bound_drivers" and "network_events" don't need to be used in Nova itself
14:31:10 <amotoki> it sounds that we would like to abstract what capabilities are support by drivers.
14:31:10 <sean-k-mooney> network_event would need to be used by nova
14:31:25 <njohnston> amotoki: +1
14:31:26 <sean-k-mooney> bound_drivers woudl mainly be used by os-vif
14:31:42 <sean-k-mooney> there is one usecase where it would be useful for bandwtiht based schduling
14:31:45 <ralonsoh> ok, sorry yes
14:32:13 <ralonsoh> amotoki, capabilities? do you mean type of events?
14:33:07 <amotoki> ralonsoh: kind of such. I don't see concrete events right now but I think some abstractions are needed from this discussion
14:33:28 <mlavalle> so let me attempt to summarize the situation, can I?
14:33:37 <ralonsoh> amotoki, for sure, something commonly defined both for neutron and nova
14:33:43 <ralonsoh> please, mlavalle
14:34:31 <mlavalle> 1) Currently, we have Neutron communcating to Nova, through the binding and events, the status of a port
14:35:47 <mlavalle> 2) The semantics of these communcations are not sufficient today for Nova / os-vif to meaningfully work wit  thos e ports. We nneed more finely garined semantics
14:35:53 <mlavalle> agree so far?
14:36:05 <sean-k-mooney> yes
14:36:17 <amotoki> +1
14:36:21 <njohnston> +1
14:36:32 <slaweq> yes
14:37:03 <mlavalle> 3) on the Neutron side, I think amotoki and njohnston are concerned about communicating data that is too much back end implementation dependent
14:37:40 <mlavalle> 4) Therefore their question is, can we abstract a little bit the semantics of what will be communicated
14:37:59 <mlavalle> agree so far amotoki, njohnston?
14:38:03 <amotoki> yes. as of now, we pass bound driver information.
14:38:08 <njohnston> yes
14:38:50 <ralonsoh> amotoki, yes but we need the bound drivers nested list
14:39:07 <sean-k-mooney> we could drop the boud driver info an still support alot of the usecase
14:39:08 <amotoki> I am not sure it is the right direction to expand the current approach using driver information for further processing.
14:39:30 <amotoki> it would be easy to use the list of drivers though.
14:39:38 <sean-k-mooney> amotoki: but to be clear the lack fo driver info has cassed several security bug in the past
14:39:57 <amotoki> sean-k-mooney: yeah, I know.
14:40:18 <mlavalle> Ideally, all the backends should have the same semantics for the same events, but the ugly reallity is that the backends have interpreted these semantics in different ways
14:40:26 <amotoki> it tends to depend on implementations.
14:40:33 <mlavalle> and that is how we find ourselves in this situation
14:41:03 <mlavalle> each backend evolved on its own
14:41:06 <sean-k-mooney> mlavalle: well they all have the same event but they send them at different time so the semantic difference it the problem i hope we can solve.
14:41:32 <mlavalle> sean-k-mooney: that's exactly what I mean
14:41:48 <mlavalle> all send the same events, but they really mean different things
14:41:56 <sean-k-mooney> yep
14:41:57 <mlavalle> right?
14:42:42 <mlavalle> so in an ideal world maybe we should go to the backends and attempt to align the semantics
14:42:54 <mlavalle> but that is not likely to happen, right?
14:43:02 <slaweq> mlavalle: that will not gonna happen for sure :)
14:43:03 <sean-k-mooney> the envent in question for clarity are "network-vif-plugged" "network-vif-unplugged" "network-vif-deleted" and "network-chagned"
14:43:14 <mlavalle> yeap
14:43:55 <mlavalle> so I think sean-k-mooney and ralonsoh are taking the pragmatic approach
14:44:26 <mlavalle> let's fix it in a combination of more data in the binding + nova anmd os-vif changes
14:44:27 <ralonsoh> (drilling a hole though Nova)
14:44:40 <mlavalle> is that agood summary?
14:44:46 <ralonsoh> sure
14:44:49 <sean-k-mooney> yes more or less
14:44:53 <ralonsoh> We'll amend the spec
14:45:02 <njohnston> makes sense
14:45:16 <sean-k-mooney> i would like neutron/ the ml2 dirves to declar the semantic of what the event means to them
14:45:23 <sean-k-mooney> and then teach nova to deal with that
14:45:35 <sean-k-mooney> but not teach nova about the 50 or so neutron backends
14:45:43 <amotoki> sounds good. both sides need to have same interpretations.
14:45:58 <mlavalle> I think amotoki's and njohnston concerns about abstractions are correct
14:46:31 <mlavalle> precisely because we don't want to have to teach nova to deal with 50 neutron backends
14:46:45 <amotoki> yeah
14:47:05 <slaweq> I agree
14:47:11 <njohnston> +100
14:47:15 <sean-k-mooney> yes for what its worth we could remove the bound_drivers from this spec and i can deal with that issue seperately
14:47:28 <sean-k-mooney> that would leave just the abstack connectivy and events items
14:47:32 <sean-k-mooney> if that would help
14:47:39 <mlavalle> and I think the last three lines typed by sean-k-mooney capture perfectly a good middle ground we can all agree on
14:48:00 <mlavalle> niot thse last 3 lines, the 3 previous ones
14:48:14 <sean-k-mooney> :)
14:48:27 <mlavalle> can we all agree on those 3 lines?
14:48:29 <njohnston> yes, the declaration of the semantic meaning of the events in a driver-independent way is the thing
14:49:11 <amotoki> agree
14:49:27 <njohnston> like sending an "unreliable plugging" flag for linuxbridge or a "plug before dataplane config" for odl
14:50:16 <sean-k-mooney> njohnston: if we can also agree on sorter names for those flags that would make me happy :)
14:50:30 <njohnston> sean-k-mooney: absolutely :-)
14:50:34 <mlavalle> slaweq, haleyb: what do you think?
14:51:12 <slaweq> I agree with Your summary and IMO this rfe can be approved
14:51:22 <haleyb> +1 from me too
14:51:24 <slaweq> we can discuss details in spec review
14:51:30 <mlavalle> so here's what I propose
14:52:05 <mlavalle> 1) I'm going to capture sean-k-mooney's magic 3 lines in the RFE, so they can guide us as the priciples for this effort
14:52:31 <mlavalle> 2) Approve the RFE so we can focus on developing the spec along those principles
14:53:10 <njohnston> +1
14:53:19 <mlavalle> 3) sean-k-mooney don't remove things just yet. let's see if in the spec review process we can accomodate everything. if that is not possible, then we drop stuff
14:53:32 <slaweq> +1
14:53:35 <sean-k-mooney> :)
14:53:37 <sean-k-mooney> sure
14:53:47 <ralonsoh> thank you all!
14:53:52 <amotoki> sounds fine to me
14:54:52 <mlavalle> haleyb: ok with you?
14:56:19 <haleyb> sure
14:56:24 <mlavalle> ok team
14:56:44 <mlavalle> This was a heavy one and I think the discussion was really insightful
14:57:01 <amotoki> njohnston: btw, I left a comment on https://bugs.launchpad.net/neutron/+bug/1821208. hopefully you can check it (though we could not cover it today).
14:57:02 <openstack> Launchpad bug 1821208 in neutron "[RFE] Only enforce policy when selected option does not match default" [Wishlist,Confirmed]
14:57:11 <mlavalle> this is good stuff
14:57:16 <njohnston> amotoki: Will check it, thanks!
14:57:21 <mlavalle> have a great weekend!
14:57:27 <mlavalle> and thanks for attending!
14:57:33 <slaweq> thx
14:57:36 <slaweq> o/
14:57:40 <amotoki> o/
14:57:41 <sean-k-mooney> o/
14:57:45 <mlavalle> #endmeeting