16:01:01 <Sukhdev> #startmeeting networking_ml2
16:01:03 <openstack> Meeting started Wed Aug 19 16:01:01 2015 UTC and is due to finish in 60 minutes.  The chair is Sukhdev. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:04 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:06 <openstack> The meeting name has been set to 'networking_ml2'
16:01:27 <Sukhdev> Welcome to the ML2 weekly meeting
16:01:37 <Sukhdev> #topic: Agenda
16:01:42 <Sukhdev> #link: https://wiki.openstack.org/wiki/Meetings/ML2
16:02:09 <Sukhdev> #topic: Announcements
16:02:31 <Sukhdev> The FF for liberty is fast approaching - so, be watchfu
16:02:35 <Sukhdev> watchful
16:03:15 <Sukhdev> I do not have any other announcements - does anybody else have any?
16:03:36 <rkukura> I’m hoping to finsh up the DVR code/schema cleanup patches before FF, and would appreciate reviews when ready
16:04:09 <Sukhdev> rkukura: let us know when you push the patches
16:04:26 <rkukura> Sukhdev: OK, thanks
16:04:57 <Sukhdev> #topic: Action Items from pervious weeks
16:05:36 <Sukhdev> there was an action item for rkukura and Sukhdev to organize the agenda around the summits/release
16:06:08 <Sukhdev> rkukura: do you have any thoughts around it?
16:06:22 <rkukura> haven’t had a chance to work on it
16:06:30 <Sukhdev> Did you mean to include Mitaka release as well summit related agenda
16:07:37 <rkukura> I was just thinking we’d track whatever goals for mitaka we are working on, such as the async stuff, etc.
16:07:37 <Sukhdev> OK - lets discuss this off-line
16:08:05 <Sukhdev> rkukura: Oh I see - we already have that on the agenda
16:08:10 <rkukura> you’ve got all this covered in this weeks, I think
16:09:42 <Sukhdev> There is another action item - to finalize the plans for late-cycle sprint
16:10:06 <Sukhdev> rkukura: have you had a chance to follow up with the others to nail down the logictics?
16:10:18 <Sukhdev> so that folks can plan accordingly
16:10:45 <rkukura> not yet, sorry - I’ll get on that this week
16:11:04 <Sukhdev> rkukura: good - thanks
16:11:31 <Sukhdev> anybody has anything to add to this?
16:12:01 <Sukhdev> #topic: L3 Blueprints -
16:12:11 <Sukhdev> This is as an FYI on the agenda
16:12:34 <Sukhdev> #link: https://launchpad.net/neutron/+milestone/liberty-3
16:12:59 <Sukhdev> there are few ML2 related Bps in the list
16:13:23 <Sukhdev> feel free to review/follow up with the authors
16:14:13 <Sukhdev> since shivharris and asoumya are not here, I am going to skip over the physical topology discussion
16:14:35 <Sukhdev> rkukura: have you heard any progress from Arvind? '
16:15:05 <rkukura> no - I think I was supposed to contact him, but haven’t - will this week
16:15:07 <Sukhdev> he mentioned they were planning on making a submittal for Tokyo summit
16:15:31 <Sukhdev> OK - in that case, lets move along with the agenda
16:15:52 <Sukhdev> #topic: driver API for SecurityGroup
16:16:27 <yamamoto> i added it
16:16:42 <Sukhdev> yamamoto: yes, please take the stage -
16:17:29 <yamamoto> ml2 assumes rpc/agent-based security group implementatin and the md interface lacks relevant operations.
16:17:44 <yamamoto> https://bugs.launchpad.net/neutron/+bug/1444112
16:17:44 <openstack> Launchpad bug 1444112 in networking-odl "ML2 security groups only work with agent drivers" [High,In progress] - Assigned to Kyle Mestery (mestery)
16:18:12 <yamamoto> it's workarounded by using callbacks.
16:18:33 <yamamoto> but it's nicer to have more proper md interface for sg.
16:18:39 <yamamoto> how do you think?
16:19:26 <Sukhdev> yamamoto: would you like to see a more like a two-way handshake based interface?
16:20:31 <yamamoto> sure, usual pre/postcommit api would be good, at least for consistent reasons.
16:20:33 <rkukura> yamahata: I think SG flexibiltiy for MDs should be a goal for mitaka
16:21:33 <rkukura> This is an interesting case where we need to guarantee that at least one MD is enforcing the SGs for every port binding, even with hierarchical bindings and heterogeneous deployments.
16:22:02 <rkukura> It also may be worth thinking about whether this needs a SG-specific mechanism, or something more general that could do the same for other extensions.
16:23:19 <Sukhdev> shall we consider proposing a design session in Tokyo for this?
16:24:31 <Sukhdev> yamamoto: do you have any thought around it?
16:24:40 <rkukura> Sukhdev: I’m in favor of that, but it would be most valuable if there were a concrete proposal to discuss.
16:25:10 <yamamoto> sure.  i don't have a concrete proposal.  just "wondering".
16:26:01 <yamamoto> rkukura: do you have any example of other extensions?
16:26:08 <Sukhdev> yamamoto: why don't we take an action to think about it and see what can we come up with?
16:26:53 <rkukura> yamamoto: I think QoS and port security are both implemented as extension drivers in ML2. Not sure if QoS involves agent RPCs.
16:27:46 <yamamoto> currently extension drivers can merely add attributes to core resources, right?
16:28:00 <yamamoto> ie. not new CRUD ops
16:28:09 <rkukura> yamamoto: right - new resources require service plugins
16:29:40 <rkukura> We’ve talked a bit about enforcing semantics for extension drivers (as followup work to what’s there now), and maybe this is similar but for other resources.
16:30:22 <yamamoto> rkukura: sg vs address-pairs vs port-sec thing?
16:31:34 <Sukhdev> so, how is the front-end implemented for security-group CRUD operations?
16:32:06 <rkukura> Port security just extends core resources, but SGs are separate resources. I think QoS does both. I’d like to come up with a scheme where ML2 port binding ensures the semantics required by the values of these sorts of extensions are provided.
16:32:30 <yamamoto> Sukhdev: front-end?
16:33:00 <Sukhdev> yamamoto: I mean who implements the security-group CLI?
16:33:52 <rkukura> I think the SG API and DB layers are built into neutron, aren’t they?
16:34:07 <yamamoto> Sukhdev: are you talking about python-neutronclient etc?
16:34:32 <yamamoto> rkukura: yes they are
16:34:59 <Sukhdev> yamamoto: the next layer - down from python-neutronclient - i.e. is it processed by a service plugin or who?
16:36:57 <yamamoto> Sukhdev: it's handled by plugins like ml2.  ml2 currently just passes them to securitygroups_db though.
16:37:32 <Sukhdev> I am thinking that may be the point to look into perhaps figure out a way to tie it into ML2 core plugin
16:38:08 <rkukura> Does the ML2 core plugin actually handle CRUD for SG APIs? I thought these were separate.
16:38:33 <yamamoto> my understanding is ml2 -> SecurityGroupServerRpcMixin -> SecurityGroupDbMixin
16:38:48 <Sukhdev> rkukura: that is the answer I am looking for :-)
16:39:01 <rkukura> OK, was just tracking that down
16:39:29 <rkukura> So ML2 could intercept these calls and call the MDs during precommit and/or postcommit
16:40:04 <Sukhdev> rkukura: yup - that is the way I am thinking - hence, was asking those questions
16:40:54 <Sukhdev> that will give yamamoto what he is looking for - however, this will require some investtigation
16:41:13 <rkukura> So that would provide a cleaner way for MDs to observe the SG CRUD operations that using the notifications, but it doesn’t address ensuring that SGs are being properly enforced.
16:44:08 <yamamoto> isn't it reasonable to say an MD which has leaf binding of the port is responsible to enforce SG?
16:45:07 <Sukhdev> yamamoto: perhaps
16:47:16 <Sukhdev> I think it is worth thinking through -
16:48:05 <Sukhdev> perhaps we can discuss it further next week and have some more ideas and see if we build a reasonable proposal that make sense to present at design summit?
16:48:09 <Sukhdev> does it make sense?
16:48:55 <yamamoto> and ideally rpc stuff should be moved out from core ml2.   probably into an MD like l2pop?
16:48:59 <yamamoto> Sukhdev: sure
16:50:16 <Sukhdev> yamamoto: I'll keep this on agenda for next week. would you be willing to lead this topic next week?
16:50:28 <yamamoto> Sukhdev: sure
16:50:39 <rkukura> its not always the bottom-most MD - SGs might be enforced in a switch
16:51:15 <yamamoto> rkukura: is there such a implementation?
16:51:34 <Sukhdev> rkukura: are you sure about it? how would you deal with the VM migrations then?
16:51:54 <rkukura> Cisco APIC does this
16:52:16 <yamamoto> it's interesting.
16:52:36 <yamamoto> anyway let's move on.  <10 mins left.
16:52:47 <rkukura> Or can do it, there is also the opflex agent on the host that can enforce policy, but that should be optional
16:54:06 <Sukhdev> rkukura: I guess as long as at least one MD enforces it (kind of like at least one MD has to bind the port) - perhaps that might do it
16:54:27 <Sukhdev> moving right along -
16:54:31 <rkukura> Sukhdev: agreed
16:54:54 <Sukhdev> #topic: modular l2 agent & macvtap
16:55:20 <Sukhdev> scheuran is not here - but, he has posted the summary on the agenda
16:55:31 <Sukhdev> I hope everybody has had a chance to review it -
16:55:58 <Sukhdev> I kind of like their approach
16:56:29 <Sukhdev> since scheuran is not here, do not know if there is anything we want to discuss
16:56:42 <Sukhdev> #link: https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:bug/1468803,n,z
16:57:09 <Sukhdev> review the patches posted by the above link
16:57:17 <Sukhdev> anything else on this topic?
16:57:28 <Sukhdev> #topic: Open Discussion
16:57:46 <Sukhdev> We managed to get to Open Discussion without running out of time :-)
16:57:55 <yamahata> hello. regarding to ML2 plugin sync, is there PoC code? or document only?
16:58:00 <yamahata> I mean https://docs.google.com/document/d/17fATwZkJEonH0pIb1-mPD0UB5RKnJzcHYqkBesJhirE/edit?pli=1
16:58:19 <Sukhdev> yamahata: there is POC code available
16:58:33 <yamahata> Very cool. link? I couldn:t find it.
16:58:34 <Sukhdev> yamahata: I reviewed it a while back
16:58:44 * Sukhdev looking
16:58:58 <yamahata> btw, I could find task flow patch.
16:59:21 <rkukura> https://review.openstack.org/#/c/154333/
17:00:05 <Sukhdev> rkukura: thanks you beat me to it :-)
17:00:20 <yamahata> thanks.
17:00:27 <rkukura> Just searched our massive agenda page ;)
17:00:31 <Sukhdev> yamahata: will you be joining us for the sprint?
17:00:47 <yamahata> I'm planning to do so.
17:00:54 <yamahata> Should I register myself at etherpad?
17:01:05 <rkukura> yamahata: yes, please
17:01:24 <Sukhdev> yamahata: great - please read the specs, the code, and reach out to rkukura, manishg or myself
17:01:26 <yamahata> rkukura: sure.
17:01:32 <Sukhdev> folks we are out of time
17:01:36 <Sukhdev> thanks for attending
17:01:40 <Sukhdev> bye
17:01:42 <yamamoto> bye
17:01:43 <rkukura> thanks Sukhdev!
17:01:44 <Sukhdev> #endmeeting