16:02:30 <rkukura> #startmeeting networking_ml2 16:02:31 <openstack> Meeting started Wed Apr 6 16:02:30 2016 UTC and is due to finish in 60 minutes. The chair is rkukura. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:02:32 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:02:35 <openstack> The meeting name has been set to 'networking_ml2' 16:02:35 <scheuran> hi 16:02:58 <rkukura> #topic Agenda 16:03:04 <rkukura> #link https://wiki.openstack.org/wiki/Meetings/ML2#Meeting_April_6.2C_2016 16:03:17 <rkukura> Does anyone want to add/remove anything from the agenda today? 16:03:53 <rkukura> should be a relatively quick meeting today 16:04:02 <rkukura> #topic Announcements 16:04:15 <rkukura> The Mitaka release is this week 16:04:32 <rkukura> Newton summit is approaching 16:04:39 <rkukura> and, … 16:04:54 <rkukura> today is Sukhdev_’s birthday! 16:05:43 <Sukhdev_> It was my turn to chair - hence, Bob graciously agreed to chair 16:06:12 <scheuran> Sukhdev_, happy birthday!! 16:06:31 <rkukura> Sukhdev_ did the agenda, and kept it nice and short, so I’m happy to do it! 16:06:33 <Sukhdev_> Thanks scheuran 16:06:39 <rkukura> any other announcements? 16:07:10 <rkukura> #topic Design Summit Ideas 16:07:21 <rkukura> #link https://etherpad.openstack.org/p/newton-neutron-summit-ideas 16:08:21 <Sukhdev_> If you look at item 1, I am trying to get a session for Manila integration with Neutron - 16:08:26 <rkukura> We’ve got a couple of ML2 items, some OVS items, and others that will impact ML2 I’m sure 16:08:33 <Sukhdev_> this really has to do with HPB 16:09:19 <Sukhdev_> Number of total session for Neutron is 9 - so, it is going to be tight 16:09:26 <rkukura> Sukhdev_: Yes, I’ve had some conversions regarding this as well - its really that Manilla was assuming the providernet extension was all it needed to know to attach to networks, which never was really guaranteed 16:09:42 <rkukura> Maybe a manilla session for that one? 16:10:14 <rkukura> That might also be something we can discuss with the appropriate manilla people on Friday 16:10:43 <rkukura> Anything missing that should be discussed at the summit? 16:10:52 <Sukhdev_> rkukura : Yup - Friday session will be good 16:11:05 <rkukura> meetbot was not running last week, so its possible something was mentioned that I don’t recall 16:11:35 <Sukhdev_> rkukura : I discussed with armax to group some of these topics into one session 16:12:32 <rkukura> ok 16:12:43 <Sukhdev_> for instance, visibility into segments of a network (added by rkukura), and manila requirements, routed network's segments, etc.. 16:13:01 <Sukhdev_> all related to visibility into HPB and segments related to a network 16:13:23 <yamamoto> rkukura: missing part of log: http://paste.openstack.org/show/492483/ 16:13:53 <rkukura> yamamoto: thanks! 16:15:02 <rkukura> I just noticed the PBAM idea on the etherpad - this looks like some kind of alternative to backend-specific ML2 extension drivers, so might be of interest 16:15:59 <rkukura> Sukhdev_: Did armax say when he’d have an initial session schedule ready? 16:16:13 <Sukhdev_> no 16:16:23 <rkukura> OK 16:16:31 <rkukura> Anything else on this topic? 16:16:39 <Sukhdev_> I think the deadline to putting sessions on schedule is April 17 16:16:57 <Sukhdev_> so, probably some time next week 16:17:10 <rkukura> thanks 16:17:39 <rkukura> #topic Migration and Port Binding 16:18:14 <rkukura> scheuran: I added the links to my old DVR cleanup patch and bug to last week’s agenda 16:18:27 <scheuran> rkukura, oh cool, have not yet seen it 16:18:31 <scheuran> thanks 16:18:45 <rkukura> Do you have any update for us? 16:18:59 <scheuran> #link https://review.openstack.org/297100 16:19:11 <scheuran> ^ this is the prototype - did some refactoring 16:19:26 <scheuran> and the nova live migration guys asked me to write down a nova spec 16:19:38 <scheuran> #link https://review.openstack.org/301090 16:20:17 <scheuran> haven't found any showstopper so far 16:20:34 <rkukura> scheuran: Thanks! 16:20:37 <scheuran> rkukura, but I'll also have a look at your patchset regarding portbinding, maybe this is a good alternative 16:20:42 <scheuran> that's it 16:21:28 <rkukura> So this approach just updates the port with the new host_id, land uses the port binding results for the new activation of the instance? 16:21:51 <scheuran> rkukura, exactly 16:22:13 <rkukura> This sounds like it should be sufficient in many cases 16:22:18 <scheuran> and on migration failure, I set the host_id back to the source port 16:22:25 <rkukura> makes sense 16:23:03 <rkukura> If some ML2 MD immediately stopped the flow of traffic when its port binding was torn down, would that be a problem with this approach? 16:23:40 <scheuran> rkukura, yes 16:23:44 <scheuran> that would be a problem 16:24:03 <scheuran> cause it might take some time to migrate the instance 16:24:10 <scheuran> in this timeframe it is not available 16:24:49 <rkukura> Is there an assumption both run at the same time? Or should there be a separate explicit cut-over of traffic after the new one is ready? 16:25:24 <scheuran> rkukura, there is a explicit cut over 16:25:40 <scheuran> so for a few millisends it is not reachable 16:26:09 <rkukura> scheuran: How is that cutover implemented in terms of the Neutron API? 16:26:56 <scheuran> rkukura, sorry, I didn't get the question 16:27:08 <scheuran> Neutron API is not affected at all, I think 16:27:40 <scheuran> nova triggers the migration (e.g. via a command to libvirt) 16:27:59 <scheuran> libvirt starts migrating 16:28:00 <rkukura> OK, maybe that is all that’s needed 16:28:16 <scheuran> at one point, libvirt decides to pause the source 16:28:19 <scheuran> copy over the rest 16:28:25 <scheuran> and activate the instance on the target 16:28:38 <scheuran> after that succeeded, nova updates the portbinding 16:29:09 <rkukura> So the assumtion is that Neutron will allow traffic to/from both VMs while this is happening? 16:29:38 <scheuran> rkukura, yes 16:29:42 <rkukura> And libvirt is what’s ensuring only one is active on the network at any one time? 16:29:57 <scheuran> rkukura, yes 16:30:22 <scheuran> you will never have 2 running instances 16:30:31 <scheuran> at least one is in paused state 16:30:40 <scheuran> always 16:31:12 <rkukura> OK, for the reference implementation we are probably OK, but I’m a bit concerned that some MDs may need to know not to stop traffic immediately when the port is initially unbound. 16:31:12 <scheuran> but what could be problematic is a scenario where you have a sdn controller 16:31:22 <scheuran> rkukura, agree 16:31:53 <rkukura> So this is where the distributed binding support may be needed. 16:32:07 <scheuran> rkukura, yep 16:32:10 <yamamoto> fyi, midonet has the exact problem 16:32:17 <scheuran> why did it never land? 16:32:43 <rkukura> I never had time to complete the patches 16:32:52 <scheuran> yamamoto, ah interesting - so you're shutting down the port when the binding:host_id changes? 16:32:57 <rkukura> And it kind of fell off everyone’s priority list 16:33:37 <scheuran> rkukura, ok - so there's still another use case for it 16:34:07 <yamamoto> scheuran: well, it isn't binding:host_id. (so not the exact problem acutually) it stops the traffic on from-host when nova plugs the port on the to-host. ie. pre-livemigration 16:34:55 <scheuran> yamamoto, ah ok 16:35:20 <scheuran> yes, that's another problem 16:35:30 <scheuran> yamamoto, but do you have an idea how to get around? 16:36:32 <yamamoto> scheuran: no idea. but i suspect it needs some explicit notification from nova, or multiple-plugging support in midonet-side. 16:36:43 <scheuran> rkukura, so let me have a look at your patches until next week. I can find it in the meeting logs of last weeks meeting, right? 16:37:05 <rkukura> Yes, or in the agenda from last week 16:37:25 <yamamoto> scheuran: let me know if you have a better idea 16:37:32 <rkukura> So it sounds to me like scheuran’s nova patch is a good first step, but some addtional work may be needed. 16:37:33 <Sukhdev_> #link: https://bugs.launchpad.net/neutron/+bug/1367391 16:37:35 <openstack> Launchpad bug 1367391 in neutron "ML2 DVR port binding implementation unnecessarily duplicates schema and logic" [Medium,In progress] - Assigned to Robert Kukura (rkukura) 16:37:46 <rkukura> Sukhdev_: thanks 16:37:50 <Sukhdev_> #link: https://review.openstack.org/#/c/189410/ 16:38:15 <scheuran> rkukura, agree 16:39:00 <scheuran> yamamoto, sure 16:39:19 <rkukura> Anything else on this for today? 16:39:22 <scheuran> no 16:39:54 <rkukura> #topic Open Discussion 16:40:40 <rkukura> Anything to discuss? 16:40:41 <yamamoto> wrt live migration, i want to see this finished https://review.openstack.org/#/c/274097/ 16:41:25 <scheuran> yamamoto, me too :) 16:41:40 <Sukhdev_> rkukura : We should plan for a session on Friday during Austin summit 16:41:59 <rkukura> agreed 16:42:28 <rkukura> Anything else to discuss today, or can we wrap up and let Sukhdev_ get back to celebrating! 16:42:47 <Sukhdev_> nothing from me - 16:43:18 <rkukura> ok, last call… 16:43:32 <rkukura> thanks everyone! 16:43:38 <rkukura> #endmeeting