18:03:01 #startmeeting networking_policy 18:03:02 Meeting started Thu Jun 5 18:03:01 2014 UTC and is due to finish in 60 minutes. The chair is rkukura. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:03:03 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:03:05 The meeting name has been set to 'networking_policy' 18:03:39 #link agenda: https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy 18:04:05 Not a lot on the agenda today, so hopefully a quick meeting 18:04:13 rkukura: one can hope 18:04:13 hi, sorry i am late 18:04:35 banix: Just starting - Sumit is out so I am chairing today 18:04:46 rkukura: sounds good 18:05:04 #topic Gerrit Reviews 18:06:00 The new initial series of patches for the API, DB, and Plugin layers for EP, EPG, and L2/3 Policy resources are in review, links in the agenda 18:06:41 I’m working on the next series, expecting to post the following: 18:07:10 These are all for the GroupPolicyMapping extension that adds the links to traditional neutron resources 18:07:36 API and DB layer - hopefully today, cleaning up and adding more unit tests 18:07:52 plugin layer with dummy driver - tomorrow 18:08:13 Implicit L2/L3 policy resource driver - next week 18:08:20 Mapping driver - next 18:08:20 there was a question by cgoncalves regarding the ML2 structure of the plugin and possibility of having multiple driver (that i missed on the ML unfortunately) 18:08:23 next week 18:08:51 cgoncalves: Do you want to discuss this now? 18:08:59 rkukura: so the implicit drivers will use python-client, right? 18:09:09 rkukura: not a good time? 18:09:21 banix: Now is fine - light agenda 18:09:39 sure; thought it was related to reviews. 18:09:42 s3wong: we agreed last week to use python-neutronclient for the mapping driver 18:10:03 s3wong: we could for implicit resource driver, or could use direct plugin calls for that 18:10:53 do we see having multiple drivers for group policy as the usage; i know the plugin is done so we can do it but in my thinking we will have mainly one driver from group policy for a given instance of OpenStack 18:10:56 One use case for the ML2-like multiple driver support is having both the implicit resource and mapping drivers called 18:11:02 rkukura: OK - just trying to see if the 'redirect' action needs to migrate to python-neutronclient as well 18:11:04 do you guys see this differently? 18:11:29 rkukura: i see 18:11:42 s3wong: If that is acting on the firewall or router APIs, it should use the client library 18:12:13 rkukura: agreed 18:12:38 Is there any valid use case for a deployment mixing multiple ways to enforce the policies? 18:13:04 rkukura: not that i can think of 18:13:47 We do support that kind of thing in ML2, with port binding determining which driver “controls” each port, but not sure if we could/should try to do something similar in GP 18:14:36 rkukura: There might be a difference between say the driver for managing the virtual resources (using vswitch) and physical resources (using a mech_driver) 18:14:52 rkukura: that was my thinking as well. so the group policy driver is more like the firewall drivers of sec groups where you pick one and use it 18:15:07 rkukura: I agree that we do need a binding like concept yet 18:15:26 mandeep: Do you mean “do need” or “do not need”? 18:15:40 rkukura: Ooops! I meant do not need ;-) 18:15:51 that’s better :) 18:16:31 Is everyone OK with keeping the list of drivers so we can package the implicit creation and mapping as separate drivers at least, even if we are not yet trying to support multiple concurrent drivers enforcing policy? 18:16:42 rkukura: +1 18:16:43 Agreed 18:16:53 mandeep: you are saying we may need to drivers at the same time one for vswitches one for phys switches 18:16:55 Not sure if cgoncalves is here? 18:17:24 rkukura: sounds good 18:17:31 banix: I was saying that there might be a use case where we split them that way (so we can get reuse for say OVS related driver) 18:17:42 OK, lets go with that for now at least, and revisit it in the review if necessary 18:18:08 banix: mandeep: probably too early to think about such use case 18:18:23 ok 18:18:48 banix: s3wong: Agreed that was potentially for later. For now, let us stay with distinction between generic functions and specific mapping. 18:19:12 Lets keep up with the sub-team reviews on the patches that are already posted, and those coming over the next week 18:19:59 Would be nice if at least a couple were merged for juno-1, provided that the gate backlog issue gets resolved 18:20:26 Anything else today on the topic of gerrit reviews? 18:21:11 #topic Mapping attribute names 18:22:14 One question that came up as I’ve been cleaning up the mapping API patch for review is whether we want to stick with the “neutron_” prefix on the names of the attributes that map to neutron resources 18:22:34 It strikes me as implying that the GP resources are not neutron 18:23:22 But they do make it very clear that these are the mapped resources, and that “port” is refers spefically to a neutron port as opposed to a TCP/UDP port 18:23:35 Anyone else share my concern on this, or should we stick with the current names? 18:24:06 rkukura: Link to review? I'm afraid I'm playing catchup 18:24:45 marun: The new patch for the mapping API extension isn’t posted yet, but these are in the original PoC WIP patches 18:25:18 rkukura: ok, maybe I'll wait till you post it and I can see the context. 18:25:31 marun: https://review.openstack.org/#/c/93935 18:26:28 I’ll stick with the neutron_ names for the upcoming patches, and we can discuss this in the reviews if needed 18:26:42 rkukura: sounds good 18:26:44 i think using neutron_* is more to the point 18:26:53 rkukura: yes, sure 18:27:02 rkukura: I share your concern, though 18:27:03 banix: I undestand that argument, and am happy with it 18:27:22 rkukura: +1 18:27:34 we could call them “mapped_port”, “mapped_network”, … 18:27:38 rkukura: given that all other extensions use 'network_id' rather than 'neutron_network_id', I'm not sure why gp should be an extension 18:28:06 rkukura: I mean, at the db level the field will be called network_id, yes? 18:28:13 marun: Thats kind of my point - if its neutron, we know what network_id means 18:28:14 grr 18:28:22 that second extension -> exception 18:29:04 rkukura: Looking at it, I think it makes sense to remove the prefix 18:29:23 Any other opinions on “port” vs. “neutron_port” vs. “mapped_port” vs. something else? 18:29:27 and have multi-valued attributes reflect their relationship target. 18:29:35 i.e. neutron_subnets -> subnet_ids 18:30:04 My vote would be for port_id 18:30:07 marun: I think consistency with the other neutron API extensions is a prerry strong argument 18:30:14 rkukura: +1 18:30:34 Anyone else have an opinion on this? 18:31:03 considering that mapping is always mapping to neutron resources then removing the prefix should be ok 18:32:39 rkukura: marun: agreed 18:32:51 rkukura: marun: banix: agreed 18:33:24 #agreed: remove the “neutron_” prefix from the port attributes, and include the “_id” suffix - i.e. “port_id” 18:33:45 #topic Open Discussion 18:34:09 That’s it for the agenda - anything else anyone wants to discuss today? 18:34:42 all good 18:34:58 Sumit and I had an action to look into the IPv6 issue we discussed last week, but I don’t think any progress has been made on that, and its not too critical short term 18:36:37 Looks like I had an action to suggest renaming the implicit context driver - I haven’t come up with anything better - any ideas? 18:37:13 Except replacing context with policy or resource, since we renamed L2/3 Context to L2/3 Policy ;) 18:38:12 I think I’ll go with “implicit_resource_driver” if nobody objects 18:38:23 Anything else for today’s meeting? Or are we done? 18:38:57 rkukura: I think we are don early today! 18:39:04 great! 18:39:20 Thanks everyone! 18:39:21 bye everybody 18:39:22 amazing! 18:39:24 bye 18:39:26 it has been a while! 18:39:26 #endmeeting