16:04:43 <rkukura> #startmeeting networking_ml2
16:04:44 <openstack> Meeting started Wed Mar 16 16:04:43 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:46 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:04:48 <openstack> The meeting name has been set to 'networking_ml2'
16:04:54 <rkukura> that’s encouraging
16:05:10 <rkukura> #topic Agenda
16:05:16 <mkoderer___> works
16:05:37 <rkukura> #link https://wiki.openstack.org/wiki/Meetings/ML2#Meeting_March_16.2C_2016
16:05:48 <rkukura> Anything to add?
16:05:58 <rkukura> Or subtract?
16:06:22 <rkukura> #topic Announcements
16:07:19 <rkukura> Looks like mitaka stable branch should be created, so I guess Newton work is commencing
16:07:52 <rkukura> Any other announcements?
16:08:19 <rkukura> #topic Docs ML2 configuration section update
16:08:32 <rkukura> #link https://review.openstack.org/#/c/282349
16:08:37 <scheuran> I updated the patch
16:08:56 <rkukura> scheuran: thanks - anything to point out, other than encouraging reviews?
16:09:13 <scheuran> rkukura, no
16:09:21 <Sukhdev> I had posted comments on earlier version
16:09:44 <scheuran> Sukhdev, saw that, thanks. I now posted a version that is free of any personal opinion I hope :)
16:09:56 <Sukhdev> scheuran : :-)
16:10:13 <rkukura> lets review and get this merged!
16:10:20 <scheuran> so nothing else on this
16:10:35 <rkukura> #topic Routed networks discussion
16:10:37 <Sukhdev> scheuran : no worries - I will review it again....
16:10:50 <rkukura> #link https://review.openstack.org/#/c/225384/
16:11:15 <scheuran> Sukhdev, thanks!
16:11:33 <Sukhdev> rkukura : I do not know if you had a chance to review this - but, the work has started on this
16:11:33 <rkukura> I finally reviewed the current spec, and posted a couple comments
16:11:58 <Sukhdev> :-)\
16:12:54 <rkukura> In general, I think we need to be careful about changing the meaning of a fundemental Neutron construct.
16:13:39 <Sukhdev> yup
16:14:28 <rkukura> Certainly HPB assumes L2 bridging between dynamic and static segments, and from the initial proposal, ML2 always assumed L2 bridging between segments
16:14:58 <rkukura> So if we go with this approach, I’d argue the ML2 default for l2_adjacency should be True
16:16:02 <rkukura> I’m also not really clear from the spec on how this segment_host_mapping table is supposed to be used by the plugin itself
16:16:51 <rkukura> Is the use case for routed networks one that involves lots of tenant-specific (routed) networks, or would this typically be shared by many tenants?
16:17:18 <rkukura> If the latter, I really don’t see an issue with having to pass in l2_adjacency=False when creating a routed network
16:17:52 <rkukura> Does anyone else have an opinion on any of this?
16:18:02 <rkukura> Or any other comments on the spec?
16:19:01 <rkukura> If not, we’ll move on, and maybe take this topic off the weekly agenda ;)
16:20:30 <rkukura> #topic port binding with port owned by router
16:20:53 <yamahata> Hi, I put that topic
16:20:53 <rkukura> Can whomever added this to the agenda explain the issue?
16:21:01 <rkukura> yamahata: ok, thanks
16:21:19 <yamahata> I'd like to discuss that requirement for Newton cycle
16:21:26 <yamahata> The background is as follows
16:21:45 <yamahata> the port is owned by router or other service. In my case, it's bgpvpn service.
16:21:54 <yamahata> And it's servied by ODL.
16:22:12 <yamahata> we have enabled odl mech driver and sr-iov driver.
16:22:30 <yamahata> But the port is boound to sr-iov.
16:22:48 <yamahata> I'd like to suppress binding to sr-iov somehow, when the port is owned by services.
16:23:07 <yamahata> Does this requirement make sense?
16:23:39 <rkukura> Shouldn’t the SR-IOV driver look at binding:vnic_rype to see whether it should bind? Or at least at binding:profile to see if it has the info it needs (from nova)?
16:24:01 <rkukura> Maybe this is a bug in the SR-IOV driver
16:24:43 <yamahata> That sounds plausible.
16:24:52 <yamahata> Let me look into it.
16:25:18 <rkukura> yamahata: I do agree there needs to be a way to suppress the SR-IOV driver from binging ports for which its not suitable.
16:25:24 <rkukura> binding
16:25:49 <rkukura> yamahata: should we followup on this at next week’s meeting?
16:25:50 <yamahata> In general, I'd like to see port owner specify mech driver
16:26:07 <yamahata> rkukura: not for next week.
16:26:37 <yamahata> This is input for newton planning. We'll see.
16:26:43 <Sukhdev> yamahata rkukura : Sorry I stepped away
16:27:02 <Sukhdev> yamahata : I ran into similar situation at one of the customers site
16:27:03 <rkukura> yamahata: I think the port owner can influence the binding through the binding:vnic_type, binding:profile and binding:host_id attributes, but shoudn’t really have to know the ML2 driver details of the delpyment
16:27:23 <Sukhdev> rkukura : +1
16:27:34 <yamahata> Got it. that sounds a way to go.
16:28:01 <Sukhdev> yamahata : I had to face similar situation - I used vnic-type and tenant-id to solve it -
16:28:15 <Sukhdev> keep in mind tenant-id is avaialble in the context as well
16:28:40 <Sukhdev> so, if the port is owned by service tenant - you can filter it that way as well
16:29:10 <rkukura> yamahata: Thanks for bringin this up - lets see if the existing attributes are sufficient, or if we need something new in Newton for this.
16:29:55 <yamahata> Sure. in odl case, port binding needs improvement. So those advise really help.
16:30:49 <rkukura> ok…
16:31:01 <rkukura> #topic imulate portbinding on migration target host
16:31:13 <scheuran> that's me again
16:31:13 <rkukura> scheuran: looks like you added this
16:31:35 <scheuran> so I have 2 use cases
16:31:57 <scheuran> Migration cross l2 agents (on host with lb, another with ovs), migration with macvtap l2 agent
16:32:12 <scheuran> so it's about migration
16:32:14 <scheuran> live migration
16:32:37 <scheuran> in case #1 nova needs to know which vnic_type is used on the target host
16:32:37 <rkukura> scheuran: Are you saying both the old and new bindings need to exist at the same time during migration?
16:33:01 <scheuran> rkukura, I'm not sure
16:33:19 <scheuran> so the information that nova needs is: vnic_type and vif_details to be used on the target host
16:33:35 <rkukura> scheuran: Do you mean vif_type?
16:33:41 <Sukhdev> scheuran : I thought nova already has migration support
16:33:42 <scheuran> oh yes
16:33:49 <rkukura> Normally, the tenant or nova would set vnic_type
16:34:02 <scheuran> sorry, I meant the vif_type
16:34:35 <rkukura> during migration, doesn’t nova currently update the port with the new binding:host_id, leaving the same values for binding:vnic_type and binding:profile?
16:34:48 <scheuran> rkukura, it does, but after migration happened :(
16:35:04 <scheuran> we would need that in pre-live migration
16:35:07 <rkukura> does it need to do it sooner?
16:35:13 <scheuran> right
16:35:30 <scheuran> this would be one approach...
16:35:48 <scheuran> doing the binding in pre_live migration (before migration started)
16:35:53 <scheuran> but not sure if this is the right approach
16:35:58 <rkukura> what’s the issue with nova just doing this sooner - is it that connectivity for the old binding could be broken?
16:36:38 <scheuran> rkukura, what do you mean by that?
16:37:16 <scheuran> Making this call earlier would be the most simple implementation!
16:37:20 <Sukhdev> scheuran : you should check with Aaron - he worked on this and I remember he pointed out lots of race conditions when he was doing this
16:37:35 <scheuran> Sukhdev, great pointer, thanks!
16:37:41 <rkukura> scheuran: I’m just asking why having nova update the port with the new binding:host_id during pre-live migration isn’t sufficient
16:37:53 <scheuran> it would be sufficient!
16:38:08 <rkukura> there could be race conditions around connectivity or around port status and all that
16:38:14 <rkukura> including nova notifications
16:38:25 <rkukura> I agree arosen may have some insite
16:39:03 <scheuran> ok, but you do not see a problem in general with first doing the port-binding, and then executing the migration?
16:39:21 <scheuran> cause then I'll invest into this direction...
16:39:36 <rkukura> I have some patches that have never merged that cleanup and start to generalize DVR’s distributed port support. One thought I had was that this could potentially be used to better support live migration. Maybe we could explore that.
16:40:20 <scheuran> rkukura, sure, if you have a pointer that would be great!
16:40:42 <rkukura> scheuran: I think we need some way to do the port binding for the new host_id in order to have the resulting binding:vif_type and binding:vif_details for nova to use.
16:40:55 <scheuran> right
16:40:59 <scheuran> so either do the port binding first
16:41:10 <scheuran> or what I had in mind, simulate the portbinding
16:41:25 <scheuran> so doing it, but not persisting it
16:41:50 <rkukura> scheuran: Since port binding can involve resource allocation, I’m not sure there would be any guarantee a simulation would have the same outcome as the real binding attempt
16:42:20 <rkukura> but it is worth considering
16:42:47 <rkukura> I’ll try to dig up the DVR cleanup patch, or maybe even try to rebase it and repost it
16:43:03 <scheuran> ok, so let me talk to arosen to figure out what he did in the past
16:43:12 <rkukura> The idea with this would be that both bindings could exist at the same time for the same port
16:43:21 <rkukura> lets revisit this next week
16:43:33 <scheuran> rkukura, sounds good!
16:43:41 <rkukura> anything else on this?
16:43:45 <scheuran> no
16:43:59 <rkukura> ok…
16:44:04 <rkukura> #topic Open Discussion
16:44:16 <rkukura> Anything to discuss?
16:45:01 <rkukura> If not, lets wrap up for today…
16:45:03 <Sukhdev> Oh one thisn
16:45:05 <Sukhdev> thing
16:45:07 <rkukura> Sukhdev: OK
16:45:16 <Sukhdev> Neutron PTL election is upon us
16:45:46 <Sukhdev> If anybody has urge to become PTL, please keep in mind the deadline is tomorrow
16:46:18 <rkukura> Sukhdev: I have not seen any candidate (ot non-candidacy) announcements yet
16:46:34 <scheuran> rkukura, me neither...
16:46:49 <Sukhdev> I think the deadline is tomorrow
16:46:57 <Sukhdev> to file for candidacy -
16:48:01 <rkukura> Sukhdev: thanks
16:48:09 <rkukura> Anything else before we wrap up?
16:48:15 <Sukhdev> none from me
16:48:42 <rkukura> ok...
16:48:50 <rkukura> thanks everyone!
16:48:53 <rkukura> #endmeeting