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