16:02:47 <rkukura> #startmeeting networking_ml2
16:02:48 <openstack> Meeting started Wed Jan 13 16:02:47 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:49 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:02:51 <openstack> The meeting name has been set to 'networking_ml2'
16:03:01 <sadasu> Hello!
16:03:13 <rkukura> #topic Agenda
16:03:46 <rkukura> #link https://wiki.openstack.org/wiki/Meetings/ML2#Meeting_January_13.2C_2016
16:04:03 <rkukura> Anything to add to the agenda today?
16:04:27 <rkukura> #topic Announcements
16:04:40 <rkukura> Only announcement I have is that M2 is next week
16:04:43 <rkukura> Anything else?
16:06:08 <rkukura> #topic Driver API for SecurityGroup
16:06:54 <rkukura> yalie: Can you update us on the status of this?
16:07:26 <yalie> rkukura: yes, from the discussion last week, we will work on it in next N
16:07:49 <Sukhdev> There was an action for rkukura and yalie to update the bug to get the closure for M release
16:08:08 <yalie> rkukura: so how to deal with the RFE bug now?
16:08:28 <yalie> Sukhdev: yes
16:09:11 <rkukura> I see active review on https://review.openstack.org/#/c/252755/, which adds the precommit events. Is that going into M?
16:09:31 <Sukhdev> rkukura, yalie: you may want to reply to armax's comment on the bug
16:09:53 <rkukura> Sukhdev: Yes, I plan to but just have not got to it
16:10:09 <yalie> rkukura: yes, that review is split from the RFE, and RFE will focus on only the enforcement
16:10:20 <Sukhdev> rkukura : no worries
16:10:21 <rkukura> OK
16:10:41 <rkukura> anything else on this right now?
16:10:46 <yalie> rkukura: that review for the precommit event goes well
16:11:19 <rkukura> yes, I looked at it briefly and it seems in pretty good shape
16:11:42 <rkukura> #topic limited-portsec implementation
16:12:22 <yalie> limited-portsec has a new implementation in the last week.
16:12:26 <rkukura> yalie: Also looks like good progress on https://review.openstack.org/#/c/250036/ since last week
16:12:50 <rkukura> any issues to discuss?
16:13:02 <yalie> rkukura: still issue left.
16:13:35 <rkukura> yalie: Can you summarize the issue?
16:13:46 <yalie> rkukura: the plugin still can not get the ability of supporting limit-portsec clearly
16:14:31 <yalie> now, I add the attr in portsec db, if the pulgin inherit the db class, it could call directly.
16:15:04 <yalie> but for extension in ML2, it only see portsec, and plugin could not call the db verification function
16:15:58 <yalie> the plugin can not know if it support limit-portsec or not.
16:16:28 <rkukura> yalie: Why does ML2 itself need to know if limit-portsec is enabled?
16:17:16 <rkukura> Or does it need to be configurable?
16:17:25 <yalie> I just think maybe user want to get this ability
16:18:04 <rkukura> yalie: Do you mean like querying whether an extension is supported?
16:18:09 <yalie> yes, rkukura
16:18:27 <yalie> querying whether it is supported
16:19:02 <rkukura> I guess that’s an argument for treating this as a separate extension rather than part of the portsec extension
16:19:13 <yalie> because implement it in the same extension, now user only see port-sec extention.
16:19:27 <yalie> yes
16:20:03 <rkukura> would it make sense to have two seperate extensions, but both implemented by the same DB mix-in class?
16:21:47 <yalie> that would make the current create to be 'update', because the same row maybe has been created by another one because of order in extentsion call list
16:22:42 <yalie> implement it in the same extension just to avoid the dependency/order issue
16:23:39 <rkukura> I didn’t mean a separate extension driver necessarily, just a separate extension that can be queried
16:24:19 <yalie> sepearate extension showed in supported_ext_alias of plugin?
16:24:46 <rkukura> So limitied-portsecurity would extend portsecurity, but the DB mix-in class would implement both (depending on the flag) and the ML2 extension driver would handle both in terms of the DB mix-in.
16:24:51 <rkukura> yalie: yes
16:26:29 <yalie> oh maybe, I have not figure out it but we can discuss it offline
16:26:33 <rkukura> yalie: Has the querying of support for this been raised as an issue in the review?
16:27:21 <yalie> no, I just think of it's issue when I add the testcases.
16:27:28 <rkukura> yalie: OK, I’ll try to keep up with the review, but ping me on IRC or email if you’d like to discuss it
16:27:45 <rkukura> anything else on this topic?
16:28:03 <yalie> some plugin which support it or not check  different return value.
16:28:08 <yalie> rkukura: thanks!
16:28:53 <yalie> rkukura: no more add
16:28:55 <rkukura> yalie: Is this something that some ML2 mechanism drivers would support, and others might not?
16:30:47 <yalie> rkukura: no, I want the test verify different value based on the plugin support it or not. like if plugin don't support, maybe the value filled with 'not-support'
16:31:08 <sadasu> yalie: I haven't been keeping up with the review
16:31:45 <yalie> sadasu: just my own thought, maybe it's not a problem.
16:31:46 <sadasu> but the cisco ucsm mech driver can operate in 2 modes
16:32:20 <yalie> sadasu: which 2 modes?
16:32:20 <sadasu> port-security would not be supported when the mech driver is dealing with a SR-IOV port
16:32:41 <sadasu> and would support it (possibly) if it is a virtio port
16:32:49 <sadasu> how can we take care of that case?
16:34:07 <yalie> sadasu: thanks, does that a kind of usecase of enforcement? rkukura
16:34:20 <rkukura> yalie: I was just typing the same thing
16:34:43 <sadasu> sorry, didn't get the question!
16:34:51 <yalie> rkukura: yeah
16:35:15 <sadasu> ok, that was a question for rkukura
16:35:38 <yalie> sadasu: we are thinking if this case is one kind of usecase for this : https://bugs.launchpad.net/neutron/+bug/1518087
16:35:39 <openstack> Launchpad bug 1518087 in neutron "[RFE] Method to guarantee that at least one mechanism driver implements security groups" [Wishlist,Won't fix] - Assigned to yalei wang (yalei-wang)
16:36:06 <Sukhdev> sadasu: when you say virtio port, you include trunk port as well?
16:36:21 <rkukura> We had previously been discussing yalie’s BP for enforcing SGs, which I’ve previously suggested is a more general issue for various extensions, not just SGs
16:37:55 <yalie> sadasu: when your mech driver works in mode which don't support portsec, does that mean portsec is false all the time and read-only
16:37:57 <sadasu> Sukhdev: in my case not trunk ports, just neutron virtual ports assigned to VMs
16:38:33 <yalie> sadasu: or just no this extension
16:38:40 <rkukura> In general, when we have a deployment with a mix of different mechanism drivers, what do we want to happen when the semantics required by the user’s extension values cannot be provided with certain possible bindings? Should port binding fail? Should nova scheduling take this into account somehow?
16:38:57 <sadasu> well, that mode is not a config time setting, it is based on what port type is being created/updated
16:39:25 <sadasu> rkukura: thanks for framing my question in a more generic way
16:40:23 <scheuran> sadasu, regarding sriov: the sriov agent only supports the noopfirewall driver for sec groups (it was implemented like it would support sec groups). But it has some anti spoofing support which can be enabled. not sure in which area the port security thing goes
16:40:59 <scheuran> sadasu, also with sriov virtual ports (macvtap) there's no way to implement sec groups at the moment
16:43:17 <scheuran> sadasu, oh my statement was about the sriov agent, not the cisco ucsm...
16:43:28 <sadasu> scheuran: agreed, thats why I want my mech driver to have the option of not supporting sec groups for some port types and support it for others
16:44:23 <sadasu> I think the design is currently going in the direction where the entire mech driver says it can support sec group or not almost at init time
16:44:47 <yalie> sadasu: agree
16:45:15 <rkukura> sadasu: Even if that is the case for one mech driver, what if one supports sec group and another doesn’t? We don’t handle that right now.
16:45:58 <sadasu> can we keep it at a more granular level? say at the level of ports instead?
16:46:19 <sadasu> rkukura: agreed. we need to take care of that too
16:47:21 <yalie> at least mech driver need provide the info that whether and when it support SG/extesnion or not
16:47:44 <sadasu> yalie: agreed.
16:48:44 <rkukura> I’m not sure its a question of whether or not the MD(s) support the extension, its whether they can provide the semantics required by the extension’s values
16:49:33 <sadasu> rkukura: +1. yes, that is a more accurate description
16:49:45 <yalie> rkukura: yes
16:50:11 <rkukura> Seems this topic will be a good one to discuss in Austin, hopefully with one or more concrete proposals.
16:51:34 <rkukura> #topic Open Discussion
16:51:35 <sadasu> rkukura:+1
16:51:43 <yalie> rkukura: +1
16:52:06 <rkukura> We’ve got about 8 minutes left - anything else to discuss?
16:52:06 <scheuran> a short thing regarding modular l2 agent (sorry if I missed that before)
16:52:22 <rkukura> scheuran: go right ahead...
16:52:44 <scheuran> all the smaller patchsets got merged, now it's time to make the "big" split off
16:52:48 <scheuran> https://review.openstack.org/#/c/246318
16:53:13 <scheuran> any input would be helpful!
16:53:31 <rkukura> scheuran: great work!
16:53:44 <scheuran> If I got armax right, we need to make mitaka2, otherwise it will move out
16:53:52 <scheuran> but I need to clarify this again
16:54:36 <Sukhdev> scheuran : M2 is next week - but, it can go into M3
16:54:38 <rkukura> The patch isn’t that “big” :)
16:54:49 <Sukhdev> so, there is time
16:54:54 <scheuran> that would be great
16:55:21 <scheuran> armax just dropped a note that it is in risk..so I was thinking if he meant the m2 as deadline...
16:55:27 <rkukura> Lets see if we can get it in M2, just to be safe.
16:55:30 <scheuran> it = the blueprint
16:55:40 <armax> scheuran: I didn’t mean that it must make M2
16:55:57 <rkukura> armax: Thanks!
16:56:01 <armax> scheuran: but that we simply gotta get on with it :)
16:56:09 <scheuran> armax, great news, thanks!
16:56:31 <rkukura> 4 minutes left - anything else?
16:56:33 <armax> scheuran: I’ll look at the patch you pointed me asap
16:56:43 <Sukhdev> scheuran : so, relax, you have time :-):-)
16:56:44 <armax> hopefully by the end of the day
16:56:50 <armax> Sukhdev: no!
16:57:05 <armax> Sukhdev: gotta work under the assumption that time has run out already!
16:57:06 <scheuran> armax, thank you. any input helps to make progress...
16:57:29 <Sukhdev> armax : got it
16:57:47 <rkukura> Sukhdev: Where do we stand on the adding network ID to type driver calls patch?
16:58:26 <Sukhdev> rkukura : there was a patch pushed - armax and kevinbenton provided some great feedback
16:58:53 <rkukura> Sukhdev: Saw that, but am not clear if its going forward or not
16:59:04 <armax> I thought the idea was shelved, based on the lack of feeback from the submitter
16:59:27 <Sukhdev> rkukura : No - we are considering dropping it - we figured out another way to deal with this
17:00:04 <Sukhdev> armax : correct - we came up with an alternative, which will take care of it
17:00:05 <rkukura> OK, thanks. If that’s the case, might make sense to abandon it so reviewers ignore it
17:00:24 <armax> Sukhdev: so should the bug/patch be abandoned?
17:00:25 <rkukura> Or switch to WIP
17:00:42 <Sukhdev> rkukura : yes, will abandon it or will WIP on it
17:00:55 <rkukura> we are out if time!
17:01:00 <rkukura> Thanks evevyone!
17:01:05 <rkukura> #endmeeting