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