16:02:33 <Sukhdev> #startmeeting networking_ml2
16:02:34 <openstack> Meeting started Wed Aug  5 16:02:33 2015 UTC and is due to finish in 60 minutes.  The chair is Sukhdev. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:02:36 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:02:38 <openstack> The meeting name has been set to 'networking_ml2'
16:02:50 <Sukhdev> Good morning, folks
16:02:59 <Sukhdev> #topic: Agenda
16:03:19 <Sukhdev> #link: https://wiki.openstack.org/wiki/Meetings/ML2
16:03:43 <Sukhdev> #topic: Announcements
16:04:16 <Sukhdev> Liberty FF is approaching soon - so, plan activities accordingly
16:04:35 <Sukhdev> not whole lot of time - this cycle seems a bit short :-)
16:05:04 <Sukhdev> I will be traveling next week to attend Ironic mid-cycle sprint - so, will not be here
16:05:27 <Sukhdev> Any body has any other announcements?
16:05:28 <rkukura> I can chair next week
16:05:36 <Sukhdev> rkukura: cool - thanks
16:06:07 <Sukhdev> #topic: ML2 late-cycle sprint
16:06:39 <Sukhdev> rkukura: I believe we are settled on the week of 10/5 - right?
16:06:49 <rkukura> right
16:07:01 <Sukhdev> rkukura: Have you closed off on the venue?
16:07:14 <rkukura> not yet, I’ll work on that
16:07:16 <Sukhdev> we had tree choices Cisco, Yahoo, and Brocade
16:07:41 <Sukhdev> rkukura: shall I assign you action to close off on it?
16:07:45 <rkukura> yes
16:08:01 <ijw> Sukhdev: I recommend Steins
16:08:10 <rkukura> that works!
16:08:29 <rkukura> neutral territory
16:08:33 <Sukhdev> #action: rkukura to finalize the venue and other details for the ML2 late-cycle
16:08:58 <ijw> You know you'll be spending time there anyway, might as well save the commute
16:09:06 <Sukhdev> ijw: I like your thinking process - however, we have to start in the evenings and end in the mornings :-):-)
16:09:38 <Sukhdev> ijw: Do we have a volunteer?
16:09:53 <ijw> I volunteer to be at Steins, that's about as much as you're getting from me
16:10:11 <Sukhdev> ijw: ha ha - trouble maker :-):-)
16:10:33 <Sukhdev> #link: https://etherpad.openstack.org/p/Neutron_ML2_Mid-Cycle_Sprint
16:10:59 <Sukhdev> Anything else on the ML2 late-cycle
16:11:45 <Sukhdev> ijw: BTW, we are due to pay a visit to Steins - perhaps you should take an action to arrange that...
16:12:13 <ijw> OK - Friday evening at Steins, tell your friends
16:12:17 <Sukhdev> #topic: L3 Blue prints
16:12:33 <Sukhdev> #link: https://launchpad.net/neutron/+milestone/liberty-3
16:13:17 <Sukhdev> Please have a look at the list of Bps -
16:13:33 <Sukhdev> I noticed couple of them may be of interest to this team
16:14:16 <Sukhdev> scheuran: you may want to check out - https://blueprints.launchpad.net/neutron/+spec/restructure-l2-agent
16:14:45 <Sukhdev> another one interesting is - https://blueprints.launchpad.net/neutron/+spec/ml2-qos
16:14:46 <scheuran> Sukhdev, ok - I will have a look
16:15:42 <rkukura> also https://blueprints.launchpad.net/neutron/+spec/reference-implementation-split
16:16:11 <Sukhdev> right
16:16:35 <Sukhdev> Please do take some to browse through them - and keep the FF deadline in mind
16:16:44 <Sukhdev> Anything else on this?
16:16:59 <Sukhdev> moving right along….
16:17:15 <Sukhdev> #topic: Modular L2 discussion
16:17:56 <Sukhdev> Last week we had a detailed discussion about macvtap agent/driver discussion
16:17:56 <scheuran> so I did some research and talked to banix, but the spec and concept is in a bad state
16:18:03 <Sukhdev> #link: http://lists.openstack.org/pipermail/openstack-dev/2015-August/071207.html
16:18:22 <scheuran> so starting right now and implementing the modular l2 agent just does not make sense I guess
16:18:54 <Sukhdev> scheuran: I read your response on the ML
16:18:54 <scheuran> this needs a proper design which is being discussed in a broader scope, like with ovs subject matter experts
16:19:35 <scheuran> So my proposal was either to do somehting to just share code
16:19:50 <scheuran> or do it like in the past - have a separate agent with duplicated code
16:20:13 <scheuran> but sc68cal_ brought back the idea again integrating it into linuxbridge again
16:20:33 <rkukura> I think its worth trying to share code if possible. Even that would be step towards a modular agent.
16:20:45 <scheuran> we would move out all linuxbridge related stuff to a linuxbridgemanager class and though creating an interface
16:21:00 <scheuran> rkukura, right, it would be a step towards
16:21:39 <Sukhdev> scheuran: I read sc68cal_ response on ML as well
16:21:58 <scheuran> #link https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:bug/1468803,n,z
16:22:11 <Sukhdev> scheuran: as long as you have done the due-diligence and reached at this conclusion - that is great
16:22:16 <scheuran> this is sc68cal_ work to restructure lb like ovs
16:22:51 <scheuran> he already started to move out the obvious linuxbridge stuff into a manager class
16:23:19 <scheuran> and I hope I'll find some time this week to move out the rest (I already did this in another prototype)
16:23:27 <scheuran> it will not be functional
16:23:42 <scheuran> but we will get an impression how it could look like
16:24:25 <Sukhdev> scheuran: thanks for sharing this information.
16:24:44 <scheuran> Sukhdev, we will see ;)
16:24:50 <scheuran> Sukhdev, welcome
16:24:59 <scheuran> we will share the results via the ML again
16:25:40 <Sukhdev> anybody has anything to add to this?
16:26:15 <rkukura> sounds good to me
16:26:17 <Sukhdev> scheuran: this is a great place to discuss any L2 related issues/designs - so, feel free to reach out for any help
16:26:40 <scheuran> Sukhdev, thanks! Sure I will!
16:27:23 <Sukhdev> #topic: Physical Topology discussion
16:27:45 <Sukhdev> Looks like our physical topology gang is missing
16:28:14 <Sukhdev> rkukura: are you in touch with asoumya? we have not heard any update from them for a while
16:28:56 <rkukura> I’ll check with him
16:29:09 <Sukhdev> cool
16:29:30 <Sukhdev> moving right along - we are at the end of the agenda item
16:29:38 <Sukhdev> #topic: Open Discussion
16:29:49 <Sukhdev> Anybody has anything to discuss
16:29:58 <yamamoto> hi
16:30:01 <yamamoto> i have one
16:30:11 <Sukhdev> yamamoto: please go ahead
16:30:55 <yamamoto> we want to implement midonet ml2 driver and want to ask your opinions.
16:31:27 <yamamoto> currently we plan to have a dedicated "midonet" type driver.  how do you think?
16:31:29 <yamahata> I have another tpic, but after yamamoto.
16:31:41 <Sukhdev> yamamoto: sure
16:31:45 <yamamoto> https://review.openstack.org/#/c/209367/
16:32:13 <rkukura> yamamoto: a dedicated type driver makes sense if other mechanism drivers will not be able to directly use the same network segments
16:32:20 <yamamoto> and we plan to filter out unrelated (non-midonet type network) ops at driver level
16:32:48 <Sukhdev> yamamoto: ML2 architecture allows this
16:33:03 <rkukura> right - ignore segments of types that you don’t handle
16:33:05 <yamamoto> in order to implement it, we want to modify driver api so that a driver can see what network types is used for subnets/ports
16:33:50 <rkukura> yamamoto: Aren’t the subnets and ports orthogonal to the set of L2 segments in the network and their types?
16:34:14 <rkukura> During port binding, a segment will be selected by the mechanism driver that binds the port.
16:34:42 <yamamoto> well
16:36:08 <yamamoto> when creating a port which belongs to a network whose network_type!=midonet, we want to avoid passing create_port to midonet backend
16:36:38 <yamamoto> doesn't it make sense?
16:37:02 <Sukhdev> yamamoto: for this you do not need to make change to the api - simply in ML2 driver filter out the create_port request
16:37:09 <rkukura> yamamoto: Sure, your MD can ignore ports on networks that have no segments with types it handles.
16:37:54 <yamamoto> my understanding is that currently there's no way for a driver to know network_type for create_port.
16:37:57 <yamamoto> is there any?
16:38:22 <yamamoto> besides accessing private (_-prefixed) attributes of port/subnet context
16:38:28 <Sukhdev> yamamoto: I think you need segmentation type - which is present in the context
16:38:28 <rkukura> yamamoto: I’d recommend that you look closely at whether your driver should do what it needs for a port at the point when the port is created, vs. the point when the port is bound.
16:39:10 <Sukhdev> yamamoto: here is one thought
16:39:45 <Sukhdev> when your type driver is in play, it will assign the segment ID and segment type -
16:39:59 <Sukhdev> which is available in the context when create_port() is invoked
16:40:24 <Sukhdev> your ML2 driver can ignore the request if the segment type is of no interest to you
16:40:41 <Sukhdev> does it make sense?
16:40:51 <yamamoto> how about a subnet?
16:41:39 <rkukura> yamamoto: Can’t your driver access the segments during port_create via context.network.network_segments?
16:42:17 <yamamoto> rkukura: sure we can.  we want a way which works for subnets too, though.
16:42:43 <rkukura> I see, we’d just need to add a network property to SubnetContext like the one on PortContext.
16:43:11 <Sukhdev> yamamoto: there are two ways to go about it -
16:43:19 <Sukhdev> 1) like rkukura suggested
16:43:33 <yamamoto> rkukura: yes, it's what i meant by api change.  sorry for not being clear.
16:43:58 <Sukhdev> 2) I think there is net-id in the subnet context, and you can cross check the network segment from the net-id, I think this should work
16:45:13 <Sukhdev> I think both solutions should work
16:45:24 <yamamoto> Sukhdev: we don't have an appropriate db context to use for the query for 2)
16:45:47 <rkukura> It seems reasonable to me to add SubnetContext.network just like the existing PortContext.network, to keep things consistent for drivers that need this.
16:46:29 <Sukhdev> rkukura: correct - this is a much cleaner way to do this
16:47:10 <yamamoto> ok we will try to go 1) route.  thank you!
16:47:40 <Sukhdev> yamahata: you had one too
16:47:51 <Sukhdev> yamahata: please go ahead
16:48:04 <rkukura> yamamoto: Thanks for bringing this up. I think you can treat SubnetContext.network being missing as a bug.
16:48:08 <yamahata> Okay, the issue I have is synchronization between ML2 db and SDN backend
16:48:15 <yamahata> It's related to task flow effort.
16:48:22 <yamahata> In my case, the controller is ODL.
16:48:26 <yamamoto> rkukura: sure. thank you
16:48:30 <rkukura> yamahata: Come to the late-cycle ;)
16:48:48 <yamahata> rkukura: I'll try. The venue is near.
16:49:17 <yamahata> When ML2 and SDN controller is in un-sync, we need to make then synchronized.
16:49:32 <Sukhdev> yamahata: venue is Silicon Valley - come on over here, we can use your use-case to implement the sync solution :-)
16:49:45 <yamahata> Currently we simply push all the information into the SDN controller.
16:50:00 <yamahata> Sukhdev: Sure.
16:50:10 <yamamoto> we (midonet) need taskflow stuff too.
16:50:18 <yamahata> It doesn't scale.
16:50:30 <yamahata> https://wiki.opendaylight.org/images/8/8d/Experiences_with_Neutron.pdf
16:50:41 <yamahata> The slide describes the observations.
16:51:08 <yamahata> And also the call from ML2 to the controller is racy.
16:51:17 <yamahata> There is no way to determine which is newer request.
16:51:29 <yamahata> Maybe sequence number needs to be added to each resource.
16:51:49 <Sukhdev> yamahata: We had the same issue in Arista driver as well
16:51:50 <rkukura> yamahata: I was suggesting the same thing in the task flow discussions a while back
16:52:14 <Sukhdev> yamahata: this is what had motivated me to propose a sync solution in Atlanta summit -
16:52:22 <Sukhdev> not many people jumped on it
16:52:26 <yamahata> Sure. I'm not surprised. I suppose all sdn controller have similar issues.
16:52:45 <Sukhdev> yamahata: what kind of scale are you testing this with?
16:52:59 <yamahata> For now very small. 1 or 2 nodes.
16:53:20 <yamahata> But target is a much bigger.
16:53:22 <Sukhdev> yamahata: I mean how many networks/ports?
16:53:33 <yamahata> at least thuthounds.
16:53:39 <yamahata> 1000 order
16:53:50 <Sukhdev> yamahata: we have been testing with 20K + ports/networks
16:53:57 <rkukura> I think we should start devoting some time to these discussion leading up to the late-cycle. Not sure if we should do this as part of this meeting’s agenda each week, or maybe a separate meeting.
16:54:00 <yamahata> Oh very cool.
16:54:49 <Sukhdev> yamahata: If you are willing to come to late-cycle, I can pull one of our Arista expert who has been working me to test this and solving this
16:55:34 <Sukhdev> yamahata: we have put in some proprietary solutions on the back-end as well as in our ML2 driver to solve this
16:55:45 <yamahata> Sukhdev: that sounds very great. I think those synchronization can be adopted by l2 agents.
16:56:00 <Sukhdev> yamahata: if you look at Arista ML2 driver, you will see bulk transactions - they are added to address this
16:56:13 <yamahata> Sukhdev: I'll take a look at it.
16:56:47 <Sukhdev> yamahata: I saw these issue long back and started addressing them - unfortunately, not many people stepped forward to address them
16:57:16 <Sukhdev> yamahata: So, here are few things we have done:
16:58:04 <Sukhdev> 1) the issue becomes really bad if there are multiple neutron controllers are involved (i.e. HA)
16:58:06 <yamahata> ODL has been becoming to hit the same issue.
16:59:16 <Sukhdev> We figure out a way to prevent the controller stepping over each other - e.g. one controller is in the middle of sync and the other jumps in
17:00:12 <Sukhdev> we also have sync lock between the sync theread and the normal CLI path to prevent two transactions (e.g. create/delete at the same time) on the same resource
17:00:37 <Sukhdev> and, finally the bulk operations
17:00:48 <Sukhdev> There is still lot more to be done
17:01:37 <Sukhdev> It is my goal to address these issue during the late-cycle sprint
17:01:47 <rkukura> we should wrap this meeting up
17:01:58 <Sukhdev> sorry out of time
17:02:13 <Sukhdev> yamahata: lets put this on agenda for next week and discuss further
17:02:20 <rkukura> Sukhdev: +1
17:02:21 <yamamoto> it would be nice to have such mechanisms at ml2 core or even higher level.  midonet also has its own experimental implementation of async task based communication mechanism.
17:02:21 <yamahata> Sukhdev: thank you for sharing the situation.
17:02:25 <Sukhdev> Thanks guys
17:02:27 <Sukhdev> bye
17:02:29 <yamahata> It definitively helps
17:02:32 <Sukhdev> #endmeeting