16:04:36 <rkukura> #startmeeting networking_ml2
16:04:36 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:04:40 <openstack> The meeting name has been set to 'networking_ml2'
16:04:44 <rkukura> #topic Agenda
16:04:50 <rkukura> #link https://wiki.openstack.org/wiki/Meetings/ML2#Meeting_July_13.2C_2016
16:05:06 <rkukura> Thanks Sukhdev_ for putting together a quick agenda this morning
16:05:55 <Sukhdev_> no problem
16:06:08 <rkukura> feel free to speek up if anyone wants to add/skip anything
16:06:13 <rkukura> #topic Announcements
16:06:50 <rkukura> Barcelona summit proposal deadline is 11:59 PM Pacific time tonight
16:07:18 <rkukura> I’ve got one in the works related to ML2
16:07:25 <rkukura> anyone know of others?
16:07:57 <rkukura> Neutron-2 milestone is planned for this week
16:08:05 <rkukura> Newton-2 I meant
16:08:09 <Sukhdev_> I have one - but, not related to Ml2
16:08:41 <rkukura> Sukhdev_: I’ll look for it
16:09:18 <rkukura> Neutron mid-cycle is August 17-19 in Cork, Ireland
16:09:26 <rkukura> any other announcements?
16:10:01 <Sukhdev_> none from me
16:10:03 <rkukura> #topic Bugs/RFEs
16:10:51 <rkukura> andreas_s_: Is https://review.openstack.org/#/c/309416/ the main thing to be reviewing right now regarding distributed port bindings?
16:11:20 <andreas_s_> rkukura, right some input would be helpful
16:11:32 <andreas_s_> last week another idea came up
16:11:40 <andreas_s_> it's listed in the alternatives section
16:12:15 <Sukhdev_> It is on my list to review -
16:12:18 <andreas_s_> basically the problems with migraiton could be solved, when nova would do portbinding in pre_live_migraiton
16:12:38 <andreas_s_> but as we discussed a couple of weeks ago, this conflicts especially with ToR drviers
16:13:01 <andreas_s_> 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 <andreas_s_> neutron requires a whitelist of mech drivers combinations that are supported...
16:13:56 <andreas_s_> for all other, the classical flow like today would be processed
16:14:00 <andreas_s_> no distributed binding
16:14:09 <andreas_s_> at all
16:14:09 <rkukura> not sure I like the sound of that, but would need to think about it
16:14:21 <rkukura> would this whitelist be configured?
16:14:23 <andreas_s_> it would not solve all the issues, that's right
16:14:33 <andreas_s_> rkukura, no, hardcoded
16:14:44 <rkukura> really don’t like the sound of that
16:14:50 <rkukura> which of the 4 alternatives is this?
16:14:57 <andreas_s_> the first I guess
16:15:12 <andreas_s_> yup
16:15:23 <andreas_s_> anyhow - I have another more important questions to you guys
16:15:36 <andreas_s_> how would multiple compute bindings play together with l2pop?
16:16:14 <andreas_s_> 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 <rkukura> andreas_s_: thats a really goood question
16:16:43 <andreas_s_> but with distributed compute ports, mac1 might be reachable via vxlan-abc and vxlan-def
16:17:22 <rkukura> 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 <Sukhdev_> andreas_s_ : This will impact L2GW and its interworkings with DVR
16:17:56 <rkukura> For the VM migration use case, I guess there would need to be an explicit cutover that would update l2pop
16:18:58 <andreas_s_> Sukhdev_, oh ok, haven't thought about L2GW yet...
16:19:10 <andreas_s_> so we agree there is an issue, right?
16:19:38 <Sukhdev_> L2GW uses l2pop to add those bindings when vteps are created and macs are leared
16:20:05 <andreas_s_> so probably we need some indicator, that the current binding is a migration port and therefore processed slightly different
16:20:14 <rkukura> 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 <rkukura> 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 <andreas_s_> rkukura, specific api layers are planned anyhow
16:22:05 <andreas_s_> I mean rest apis
16:22:09 <rkukura> right
16:23:00 <andreas_s_> but probably some additional ifs in the binding code are required
16:23:26 <andreas_s_> or maybe it' sufficient to do something in l2pop mech driver
16:23:43 <rkukura> Maybe we need to kind of separate establishing the binding, which can be generic, from activating the binding
16:24:50 <andreas_s_> yes
16:24:55 <rkukura> 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 <andreas_s_> the mech_drivers have post_commit and pre_commit methods
16:26:02 <andreas_s_> l2pop fires all its rpc notifications in post_commit
16:26:31 <andreas_s_> either those 2 methods already offer some kind of separation, or we need to establish a new mech_driver interface :/
16:27:07 <andreas_s_> something else of interest: I merged both portbindings tables: https://review.openstack.org/340410
16:27:18 <andreas_s_> it's just a few functional tests I've missed
16:27:37 <andreas_s_> logic is still the same, but data is stored in same table
16:27:38 <rkukura> 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 <andreas_s_> rkukura, that was my thought as well
16:28:25 <andreas_s_> rkukura, or have a binding type field that can be 'distributed', 'normal', and 'distributed-inactive' or whatever
16:28:41 <rkukura> We maybe need to extend PortConext, but I don’t see a need to add new MD methods normally
16:28:44 <rkukura> possibly
16:29:02 <andreas_s_> let me think about this tomorrow a bit
16:29:22 <andreas_s_> https://review.openstack.org/#/c/340031
16:29:25 <rkukura> I am really sorry I have not been keeping up with these reviews day-to-day - I will try harder
16:29:32 <andreas_s_> this is a patch of anils patch series
16:30:31 <andreas_s_> 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 <andreas_s_> so he plans to finally change identification of a distributed port from dev_owner to this vif_type in portbindings db
16:31:18 <andreas_s_> I want to say 2 things
16:31:43 <andreas_s_> first, he plans to introduce some "typing" that might be helpful for our case as well
16:32:03 <andreas_s_> second, I'm not very happy in the way he's doing it - maybe you guys have an opinion
16:32:53 <rkukura> If he used the name binding_type instead of vif_type for this, would that be better?
16:33:40 <Sukhdev_> rkukura : good thinking
16:34:31 <andreas_s_> 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 <andreas_s_> if we go that way, we cannot merge the tables in the future
16:34:50 <rkukura> 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 <andreas_s_> 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 <andreas_s_> this always requires a complex db query
16:36:03 <rkukura> have you expressed this in review comments?
16:36:08 <andreas_s_> rkukura, yup
16:36:22 <andreas_s_> there's a lenghty discussion on this :)
16:36:42 <andreas_s_> So if you find some time it would be great to get some external feedback on this patch
16:36:49 <rkukura> I need to set aside a couple hours ASAP to read through these reviews
16:37:43 <andreas_s_> 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 <rkukura> 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 <andreas_s_> 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 <andreas_s_> yeah let's organize that for next week
16:39:49 <rkukura> anything else on distirbuted bindings right now?
16:39:54 <andreas_s_> no
16:40:24 <andreas_s_> it's also pretty late for him I guess
16:41:04 <rkukura> should we try to schedule a special-purpose meeting at a different time?
16:41:46 <andreas_s_> 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 <rkukura> wishfull thinking ;)
16:42:58 <rkukura> 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 <andreas_s_> rkukura, that would be great!
16:43:51 <rkukura> OK, lets touch base on IRC in a day or two and see if we want to schedule a meeting
16:44:09 <andreas_s_> perfect. I'll spend some thoughts on the l2pop thing, and how we could reuse anils patch for that
16:44:19 <rkukura> lets move on to the other feature requests on the agenda
16:44:29 <rkukura> does anyone want to discuss any of these today?
16:44:42 <andreas_s_> yup, sorry for consuming all your meeting time...
16:45:02 <Sukhdev_> andreas_s_ : it was a useful time - so, no worries
16:45:22 <Sukhdev_> rkukura : I do not have any comments on the other features -
16:45:36 <Sukhdev_> so, if the other gang is not here, we can skip
16:45:42 <rkukura> ok
16:45:50 <rkukura> #topic Open Discussion
16:45:55 <rkukura> anything else to discuss?
16:46:06 <andreas_s_> no
16:46:08 <Sukhdev_> none from me
16:46:21 <rkukura> ok, lets wrap up early then…
16:46:33 <rkukura> thanks Sukhdev_ and andreas_s_!
16:46:42 <andreas_s_> thank you guys!
16:46:43 <Sukhdev_> thanks
16:46:45 <rkukura> #endmeeting