18:03:01 <rkukura> #startmeeting networking_policy
18:03:02 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:03:05 <openstack> The meeting name has been set to 'networking_policy'
18:03:39 <rkukura> #link agenda: https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy
18:04:05 <rkukura> Not a lot on the agenda today, so hopefully a quick meeting
18:04:13 <s3wong> rkukura: one can hope
18:04:13 <banix> hi, sorry i am late
18:04:35 <rkukura> banix: Just starting - Sumit is out so I am chairing today
18:04:46 <banix> rkukura: sounds good
18:05:04 <rkukura> #topic Gerrit Reviews
18:06:00 <rkukura> 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 <rkukura> I’m working on the next series, expecting to post the following:
18:07:10 <rkukura> These are all for the GroupPolicyMapping extension that adds the links to traditional neutron resources
18:07:36 <rkukura> API and DB layer - hopefully today, cleaning up and adding more unit tests
18:07:52 <rkukura> plugin layer with dummy driver - tomorrow
18:08:13 <rkukura> Implicit L2/L3 policy resource driver - next week
18:08:20 <rkukura> Mapping driver - next
18:08:20 <banix> 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 <rkukura> next week
18:08:51 <rkukura> cgoncalves: Do you want to discuss this now?
18:08:59 <s3wong> rkukura: so the implicit drivers will use python-client, right?
18:09:09 <banix> rkukura: not a good time?
18:09:21 <rkukura> banix: Now is fine - light agenda
18:09:39 <banix> sure; thought it was related to reviews.
18:09:42 <rkukura> s3wong: we agreed last week to use python-neutronclient for the mapping driver
18:10:03 <rkukura> s3wong: we could for implicit resource driver, or could use direct plugin calls for that
18:10:53 <banix> 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 <rkukura> One use case for the ML2-like multiple driver support is having both the implicit resource and mapping drivers called
18:11:02 <s3wong> rkukura: OK - just trying to see if the 'redirect' action needs to migrate to python-neutronclient as well
18:11:04 <banix> do you guys see this differently?
18:11:29 <banix> rkukura: i see
18:11:42 <rkukura> s3wong: If that is acting on the firewall or router APIs, it should use the client library
18:12:13 <s3wong> rkukura: agreed
18:12:38 <rkukura> Is there any valid use case for a deployment mixing multiple ways to enforce the policies?
18:13:04 <banix> rkukura: not that i can think of
18:13:47 <rkukura> 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 <mandeep> 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 <banix> 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 <mandeep> rkukura: I agree that we do need a binding like concept yet
18:15:26 <rkukura> mandeep: Do you mean “do need” or “do not need”?
18:15:40 <mandeep> rkukura: Ooops! I meant do not need ;-)
18:15:51 <banix> that’s better :)
18:16:31 <rkukura> 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 <s3wong> rkukura: +1
18:16:43 <mandeep> Agreed
18:16:53 <banix> mandeep: you are saying we may need to drivers at the same time one for vswitches one for phys switches
18:16:55 <rkukura> Not sure if cgoncalves is here?
18:17:24 <banix> rkukura: sounds good
18:17:31 <mandeep> 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 <rkukura> OK, lets go with that for now at least, and revisit it in the review if necessary
18:18:08 <s3wong> banix: mandeep: probably too early to think about such use case
18:18:23 <banix> ok
18:18:48 <mandeep> banix: s3wong: Agreed that was potentially for later. For now, let us stay with distinction between generic functions and specific mapping.
18:19:12 <rkukura> 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 <rkukura> Would be nice if at least a couple were merged for juno-1, provided that the gate backlog issue gets resolved
18:20:26 <rkukura> Anything else today on the topic of gerrit reviews?
18:21:11 <rkukura> #topic Mapping attribute names
18:22:14 <rkukura> 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 <rkukura> It strikes me as implying that the GP resources are not neutron
18:23:22 <rkukura> 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 <rkukura> Anyone else share my concern on this, or should we stick with the current names?
18:24:06 <marun> rkukura: Link to review?  I'm afraid I'm playing catchup
18:24:45 <rkukura> 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 <marun> rkukura: ok, maybe I'll wait till you post it and I can see the context.
18:25:31 <rkukura> marun: https://review.openstack.org/#/c/93935
18:26:28 <rkukura> I’ll stick with the neutron_ names for the upcoming patches, and we can discuss this in the reviews if needed
18:26:42 <marun> rkukura: sounds good
18:26:44 <banix> i think using neutron_* is more to the point
18:26:53 <banix> rkukura:  yes, sure
18:27:02 <marun> rkukura: I share your concern, though
18:27:03 <rkukura> banix: I undestand that argument, and am happy with it
18:27:22 <s3wong> rkukura: +1
18:27:34 <rkukura> we could call them “mapped_port”, “mapped_network”, …
18:27:38 <marun> 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 <marun> rkukura: I mean, at the db level the field will be called network_id, yes?
18:28:13 <rkukura> marun: Thats kind of my point - if its neutron, we know what network_id means
18:28:14 <marun> grr
18:28:22 <marun> that second extension -> exception
18:29:04 <marun> rkukura: Looking at it, I think it makes sense to remove the prefix
18:29:23 <rkukura> Any other opinions on “port” vs. “neutron_port” vs. “mapped_port” vs. something else?
18:29:27 <marun> and have multi-valued attributes reflect their relationship target.
18:29:35 <marun> i.e. neutron_subnets -> subnet_ids
18:30:04 <marun> My vote would be for port_id
18:30:07 <rkukura> marun: I think consistency with the other neutron API extensions is a prerry strong argument
18:30:14 <marun> rkukura: +1
18:30:34 <rkukura> Anyone else have an opinion on this?
18:31:03 <banix> considering that mapping is always mapping to neutron resources then removing the prefix should be ok
18:32:39 <mandeep> rkukura: marun: agreed
18:32:51 <mandeep> rkukura: marun: banix: agreed
18:33:24 <rkukura> #agreed: remove the “neutron_” prefix from the port attributes, and include the “_id” suffix - i.e. “port_id”
18:33:45 <rkukura> #topic Open Discussion
18:34:09 <rkukura> That’s it for the agenda - anything else anyone wants to discuss today?
18:34:42 <s3wong> all good
18:34:58 <rkukura> 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 <rkukura> 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 <rkukura> Except replacing context with policy or resource, since we renamed L2/3 Context to L2/3 Policy ;)
18:38:12 <rkukura> I think I’ll go with “implicit_resource_driver” if nobody objects
18:38:23 <rkukura> Anything else for today’s meeting? Or are we done?
18:38:57 <mandeep> rkukura: I think we are don early today!
18:39:04 <rkukura> great!
18:39:20 <rkukura> Thanks everyone!
18:39:21 <banix> bye everybody
18:39:22 <s3wong> amazing!
18:39:24 <mandeep> bye
18:39:26 <s3wong> it has been a while!
18:39:26 <rkukura> #endmeeting