16:04:36 #startmeeting networking_ml2 16:04:36 Meeting started Wed Jul 13 16:04:36 2016 UTC and is due to finish in 60 minutes. The chair is rkukura. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:04:37 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:04:40 The meeting name has been set to 'networking_ml2' 16:04:44 #topic Agenda 16:04:50 #link https://wiki.openstack.org/wiki/Meetings/ML2#Meeting_July_13.2C_2016 16:05:06 Thanks Sukhdev_ for putting together a quick agenda this morning 16:05:55 no problem 16:06:08 feel free to speek up if anyone wants to add/skip anything 16:06:13 #topic Announcements 16:06:50 Barcelona summit proposal deadline is 11:59 PM Pacific time tonight 16:07:18 I’ve got one in the works related to ML2 16:07:25 anyone know of others? 16:07:57 Neutron-2 milestone is planned for this week 16:08:05 Newton-2 I meant 16:08:09 I have one - but, not related to Ml2 16:08:41 Sukhdev_: I’ll look for it 16:09:18 Neutron mid-cycle is August 17-19 in Cork, Ireland 16:09:26 any other announcements? 16:10:01 none from me 16:10:03 #topic Bugs/RFEs 16:10:51 andreas_s_: Is https://review.openstack.org/#/c/309416/ the main thing to be reviewing right now regarding distributed port bindings? 16:11:20 rkukura, right some input would be helpful 16:11:32 last week another idea came up 16:11:40 it's listed in the alternatives section 16:12:15 It is on my list to review - 16:12:18 basically the problems with migraiton could be solved, when nova would do portbinding in pre_live_migraiton 16:12:38 but as we discussed a couple of weeks ago, this conflicts especially with ToR drviers 16:13:01 so the idea is that Neutron could provide an API that returns, if the current configuration can support a binding in pre_live_migration 16:13:37 neutron requires a whitelist of mech drivers combinations that are supported... 16:13:56 for all other, the classical flow like today would be processed 16:14:00 no distributed binding 16:14:09 at all 16:14:09 not sure I like the sound of that, but would need to think about it 16:14:21 would this whitelist be configured? 16:14:23 it would not solve all the issues, that's right 16:14:33 rkukura, no, hardcoded 16:14:44 really don’t like the sound of that 16:14:50 which of the 4 alternatives is this? 16:14:57 the first I guess 16:15:12 yup 16:15:23 anyhow - I have another more important questions to you guys 16:15:36 how would multiple compute bindings play together with l2pop? 16:16:14 I'm not an l2pop expert - but if I got it right, they are adding forwarding rules like - mac1 via vxlan-abc 16:16:39 andreas_s_: thats a really goood question 16:16:43 but with distributed compute ports, mac1 might be reachable via vxlan-abc and vxlan-def 16:17:22 The use cases I’ve thought about were mainly for service ports like DHCP, where there is a notion of locality or closeness 16:17:55 andreas_s_ : This will impact L2GW and its interworkings with DVR 16:17:56 For the VM migration use case, I guess there would need to be an explicit cutover that would update l2pop 16:18:58 Sukhdev_, oh ok, haven't thought about L2GW yet... 16:19:10 so we agree there is an issue, right? 16:19:38 L2GW uses l2pop to add those bindings when vteps are created and macs are leared 16:20:05 so probably we need some indicator, that the current binding is a migration port and therefore processed slightly different 16:20:14 andreas_s_: I guess I’m getting convinced there may not be a single notion of “distributed port binding” that handles the different use cases 16:21:31 So maybe the right approach is to generalize the DB layer and maybe the binding code, but have specific API actions for things like migration 16:21:56 rkukura, specific api layers are planned anyhow 16:22:05 I mean rest apis 16:22:09 right 16:23:00 but probably some additional ifs in the binding code are required 16:23:26 or maybe it' sufficient to do something in l2pop mech driver 16:23:43 Maybe we need to kind of separate establishing the binding, which can be generic, from activating the binding 16:24:50 yes 16:24:55 So in the DVR use case or maybe a distributed DHCP use case, multiple bindings would be simultaneiously active, whereas in migration and maybe HA use cases, only one would be active at a time 16:25:46 the mech_drivers have post_commit and pre_commit methods 16:26:02 l2pop fires all its rpc notifications in post_commit 16:26:31 either those 2 methods already offer some kind of separation, or we need to establish a new mech_driver interface :/ 16:27:07 something else of interest: I merged both portbindings tables: https://review.openstack.org/340410 16:27:18 it's just a few functional tests I've missed 16:27:37 logic is still the same, but data is stored in same table 16:27:38 just thinking out load here, but why not just add an ‘active’ flag to the (per-host) port bindings table, and have l2pop only fire off notications for binding/hosts that are active? 16:27:53 rkukura, that was my thought as well 16:28:25 rkukura, or have a binding type field that can be 'distributed', 'normal', and 'distributed-inactive' or whatever 16:28:41 We maybe need to extend PortConext, but I don’t see a need to add new MD methods normally 16:28:44 possibly 16:29:02 let me think about this tomorrow a bit 16:29:22 https://review.openstack.org/#/c/340031 16:29:25 I am really sorry I have not been keeping up with these reviews day-to-day - I will try harder 16:29:32 this is a patch of anils patch series 16:30:31 he now plans to use both, the vif_type of distributed binding table to store the actual vif_type, and the vif_type of the normal binding table that stores 'distributed' for a distributed port 16:31:09 so he plans to finally change identification of a distributed port from dev_owner to this vif_type in portbindings db 16:31:18 I want to say 2 things 16:31:43 first, he plans to introduce some "typing" that might be helpful for our case as well 16:32:03 second, I'm not very happy in the way he's doing it - maybe you guys have an opinion 16:32:53 If he used the name binding_type instead of vif_type for this, would that be better? 16:33:40 rkukura : good thinking 16:34:31 my point is, that this patch is reusing the existing vif_type in portbindings table for that, but the actual value of the vif_type (e.g. ovs) is still stored in the distributed table 16:34:48 if we go that way, we cannot merge the tables in the future 16:34:50 I have not looked closely enough at this patch to see if that makes any sense, but I am wondering if this serves a similar purpose to the active flag or binding type we were discussing above 16:35:29 rkukura, the problem is, that there is no easy way to figure out if a binding is distributed or not with router ha ports 16:35:42 this always requires a complex db query 16:36:03 have you expressed this in review comments? 16:36:08 rkukura, yup 16:36:22 there's a lenghty discussion on this :) 16:36:42 So if you find some time it would be great to get some external feedback on this patch 16:36:49 I need to set aside a couple hours ASAP to read through these reviews 16:37:43 so bottom line: The approach makese sense for the scope of this patch IMO, but not when having the greater picture in mind. But I might be wrong 16:38:25 andreas_s_: I really appreciate you brinding this all up here - that’s what these meetings are for. I wish anil or someone else involved in that effort could also attend 16:38:26 I could also build my stuff on those patches - but I feel it's not a good design - especially if we want to get rid of one of the bindings tables one day 16:39:35 yeah let's organize that for next week 16:39:49 anything else on distirbuted bindings right now? 16:39:54 no 16:40:24 it's also pretty late for him I guess 16:41:04 should we try to schedule a special-purpose meeting at a different time? 16:41:46 rkukura, that might be helpful - but maybe you could have a look at those patches first - maybe all makes sense and there's no need for it anymore ;) 16:42:05 wishfull thinking ;) 16:42:58 I’m in San Jose this week and schedule is pretty tight, but I’ll try to block of some time to do that 16:43:31 rkukura, that would be great! 16:43:51 OK, lets touch base on IRC in a day or two and see if we want to schedule a meeting 16:44:09 perfect. I'll spend some thoughts on the l2pop thing, and how we could reuse anils patch for that 16:44:19 lets move on to the other feature requests on the agenda 16:44:29 does anyone want to discuss any of these today? 16:44:42 yup, sorry for consuming all your meeting time... 16:45:02 andreas_s_ : it was a useful time - so, no worries 16:45:22 rkukura : I do not have any comments on the other features - 16:45:36 so, if the other gang is not here, we can skip 16:45:42 ok 16:45:50 #topic Open Discussion 16:45:55 anything else to discuss? 16:46:06 no 16:46:08 none from me 16:46:21 ok, lets wrap up early then… 16:46:33 thanks Sukhdev_ and andreas_s_! 16:46:42 thank you guys! 16:46:43 thanks 16:46:45 #endmeeting