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