18:01:39 <SumitNaiksatam> #startmeeting networking_policy
18:01:40 <openstack> Meeting started Thu May 29 18:01:39 2014 UTC and is due to finish in 60 minutes.  The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:01:41 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:01:41 <rkukura> hi
18:01:43 <openstack> The meeting name has been set to 'networking_policy'
18:01:44 <thinrichs> Hi all
18:01:51 <SumitNaiksatam> #info agenda: https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy
18:02:04 <banix> hi
18:02:14 <SumitNaiksatam> #topic Gerrit Reviews
18:02:44 <SumitNaiksatam> per the discussion last week, and based on reviewer preferences, the patches have been restructured
18:03:20 <SumitNaiksatam> so we have started with the EP, EPG, L2/3_Context resources at the head of the series
18:03:39 <SumitNaiksatam> the API, DB, and Plugin patches for these are already in
18:03:46 <SumitNaiksatam> #link https://review.openstack.org/#/c/95900
18:03:53 <SumitNaiksatam> #link https://review.openstack.org/#/c/96050
18:04:00 <SumitNaiksatam> #link https://review.openstack.org/#/c/96393
18:04:28 <SumitNaiksatam> these will be backed with the mapping driver patches, that rkukura is working on
18:04:42 <SumitNaiksatam> rkukura: ^^^
18:05:10 <rkukura> right, I expect that to be a series of 5 patches: API, DB, Plugin, Implicit Context Driver, Mapping Driver
18:05:17 <SumitNaiksatam> rkukura: ok
18:05:41 <SumitNaiksatam> so for Juno, we will be going depth and breadth
18:05:48 <SumitNaiksatam> in terms of the patch series
18:06:02 <SumitNaiksatam> *Juno 1
18:06:25 <SumitNaiksatam> so rkukura mentioned above the depth series for EP, EPG, L2/3_Context
18:06:56 <SumitNaiksatam> in parallel there will be a breadth series which will start introducing the other required resources in the model
18:07:42 <SumitNaiksatam> that way reviews can proceed in parallel on the model as well as the changes leading to the data path
18:08:05 <rkukura> SumitNaiksatam: Is our goal for Juno 1 to get the 1st 9 patches mentioned so far merged if possible?
18:08:14 <SumitNaiksatam> also, any dependencies on the model (like CLI, Heat, Horizon) can proceed in parallel with the model patches being in place
18:08:17 <rkukura> s/9/8/
18:08:24 <SumitNaiksatam> rkukura: definitely
18:08:50 <SumitNaiksatam> what do others think about this?
18:09:04 <hemanthravi> SumitNaiksatam: should we break CLI/Heat into different patches matching the model patches?
18:09:12 <armax> it's an ambitious goal, it really depends on the review churn
18:09:21 <SumitNaiksatam> armax: completely agree
18:09:27 <armax> but it's doable
18:09:36 <SumitNaiksatam> hoping for the best ;-)
18:09:38 <mandeep> hemanthravi: probably not, you can just depend on the most recent model patch
18:09:50 <banix> hemanthravi: i would say no
18:09:55 <mandeep> hemanthravi: unless the size of patch becomes too large, that is
18:10:06 <hemanthravi> ok
18:10:51 <SumitNaiksatam> i guess we need to weigh the overhead
18:11:07 <SumitNaiksatam> so while on the patches
18:11:16 <SumitNaiksatam> we had the older patches:
18:11:17 <rkukura> hemanthravi: Is the question whether to break it horizonally, with the 1st four resrouces in one patch, other resources in followup patches? If so, I’d think that depends on the size.
18:11:42 <rkukura> mandeep: That’s what I was trying to say :)
18:11:52 <mandeep> rkukura: +1 ;-)
18:12:16 <SumitNaiksatam> hemanthravi: did you get your answer?
18:12:43 <hemanthravi> yes, will group them to make the patches manageable....cli/heat should be easy to review
18:12:55 <SumitNaiksatam> hemanthravi: ok
18:13:07 <SumitNaiksatam> so i was saying, we had older patches that were causing confusion
18:13:25 <SumitNaiksatam> https://review.openstack.org/#/c/93853, https://review.openstack.org/#/c/93935
18:13:35 <SumitNaiksatam> the suggestion is to just abandon these
18:13:45 <SumitNaiksatam> agree?
18:13:53 <rkukura> SumitNaiksatam: +1, with a comment referencing the new series
18:13:57 <SumitNaiksatam> the history will still remain
18:14:03 <banix> SumitNaiksatam: yes keeping them around adds to confusion
18:14:11 <ivar-lazzaro> +1
18:14:18 <SumitNaiksatam> rkukura: yes we will note that, and the review comments will be incorporated as well
18:14:21 <mandeep> SumitNaiksatam: I agree, the PoC/prototype pieces there were creating confusion w.r.t to the final code that we expect to check-in and support
18:14:23 <banix> SumitNaiksatam: marking as abandoned seems reasonable
18:14:24 <SumitNaiksatam> banix ivar-lazzaro: ok
18:14:35 <SumitNaiksatam> mandeep: ok
18:14:51 <SumitNaiksatam> #action rkukura SumitNaiksatam to abandon older patches
18:15:11 <SumitNaiksatam> do we need to discuss anything on the current patches
18:15:17 <SumitNaiksatam> current -> newer
18:15:21 <SumitNaiksatam> i know they landed recently
18:15:34 <SumitNaiksatam> ronak has feedback and i addressed them
18:15:36 <rkukura> SumitNaiksatam: They look great!
18:15:44 <SumitNaiksatam> i just saw rkukura’s comments and i havent addresed them
18:15:46 <SumitNaiksatam> rkukura: ok
18:16:29 <mandeep> SumitNaiksatam: As armax identified, this is an big task for review. Can we get volunteers to start this review?
18:16:39 <hemanthravi> rkukura: yes, will break as your comment suggest
18:16:52 <SumitNaiksatam> mandeep: do you want me to volunteer people’s names? ;-P
18:16:55 <rkukura> In reviewing, I started thinking about what our stance on IPv6 should be in these initial series
18:17:00 <mandeep> SumitNaiksatam: I understand that we will need the datapath code to get some of these reviews forward, and that should be coming soon
18:17:16 <SumitNaiksatam> rkukura: we have a separate agenda item to discuss that
18:17:30 <SumitNaiksatam> rkukura: can we defer the ipv6 discussion to that?
18:18:03 <rkukura> SumitNaiksatam: Sure, but I’d like a clear decision on whether we are going to implement and test IPv6 during Juno
18:18:24 <mandeep> rkukura: My recommendation would be to ficus on IPv4 for Juno
18:18:39 <SumitNaiksatam> mandeep: that was my understanding
18:18:57 <mandeep> rkukura: We can come to IPv6 post-Juno, as that will be significant task in itself
18:18:58 <SumitNaiksatam> rkukura: is ipv6 support in neutron completely baked (i thought we are still implementing this)
18:19:09 <rkukura> mandeep: I’m fine with that too, with the understanding that we are including IPv6 in the API, but raising exceptions if it is used
18:19:23 <SumitNaiksatam> rkukura: that sounds like the way to go
18:19:30 <mandeep> rkukura: Good idea
18:19:49 <rkukura> As long as reviewers will be OK with that, for now.
18:20:37 <SumitNaiksatam> #agreed No ipv6 support in GP will be beyond Juno, in Juno we will have it in the resource model but will raise exception
18:20:48 <SumitNaiksatam> that did not come out right
18:21:03 <SumitNaiksatam> #undo
18:21:04 <openstack> Removing item from minutes: <ircmeeting.items.Agreed object at 0x23789d0>
18:21:18 <SumitNaiksatam> #agreed ipv6 support in GP will be beyond Juno, in Juno we will have it in the resource model but will raise exception
18:21:30 <SumitNaiksatam> ok moving on
18:21:37 <SumitNaiksatam> #topic PoC follow-up
18:21:57 <SumitNaiksatam> so last week we said that we are still working on the security groups mapping
18:22:05 <SumitNaiksatam> rkukura: over to you
18:22:46 <rkukura> Now that we’ve switched to depth-first, I’ve been focusing on the 1st series of patches rather than on the PoC
18:23:04 <SumitNaiksatam> rkukura: ok
18:23:08 <rkukura> So no new progress on the PoC
18:23:33 <rkukura> I’d like to get the 5 patches mentioned above into review as soon as possible, then switch to SG mapping
18:23:42 <SumitNaiksatam> rkukura: so i would imagine the depth-first does not include the SG mapping yet
18:23:56 <mandeep> rkukura: Agreed
18:24:06 <rkukura> At that point, we can evaluate whether this makes more sense to do in the PoC repo, or based on the gerrit master + unmerged patches
18:24:15 <SumitNaiksatam> rkukura: ok
18:24:27 <SumitNaiksatam> the other pending item from the PoC was the services’ integration
18:24:32 <SumitNaiksatam> stephen was working on it
18:24:40 <SumitNaiksatam> but he is on vacation and he provided an update
18:24:44 <rkukura> SumitNaiksatam: Correct, the SGs will come in when policy resources are added
18:24:44 <SumitNaiksatam> i will just paste it here
18:24:49 <SumitNaiksatam> rkukura: ok
18:24:59 <SumitNaiksatam> Stephen’s update: For GP, I am still looking at moving the 'redirect' code to the right place (contract creation rather than action creation). However, since there will likely be changes on how mapping driver would/should work based on Armando's comments, and that the final implementation will depend on the ServiceBase work anyway, this will likely be pushed a bit later.
18:25:50 <SumitNaiksatam> i think he is more focussed on the advanced services stuff right now to align with this
18:25:53 <SumitNaiksatam> moving on
18:26:00 <SumitNaiksatam> #topic Mapping driver/data path patches
18:26:09 <SumitNaiksatam> we covered a bit of this earlier
18:26:30 <SumitNaiksatam> but there was some discussion on the mailing lists (and also from last week)
18:26:40 <SumitNaiksatam> mainly around accessing Neutron resources (Controller versus Client)
18:26:54 <SumitNaiksatam> rkukura you have chosen an approach for this?
18:27:27 <rkukura> I think we’ve got concensus around starting out using python-neutronclient
18:27:43 <SumitNaiksatam> rkukura: ok
18:28:11 <rkukura> I’ve got reservations about that regarding performance and failure modes it introduces, but it should allow rapid progress without having to come up with a better solution
18:28:13 <SumitNaiksatam> rkukura: so the depth-first series will be implemented with the client?
18:28:23 <rkukura> That’s the plan
18:28:41 <mandeep> SumitNaiksatam: There was an action item from last week to meet with armax for an ad-hoc meeting. Since there was concensus on moving forward with client API, bot rkukura and armax felt that we did not need this meeeting anymore.
18:28:47 <LouisF> is the BP updated with the python-neutronclient design?
18:28:50 <rkukura> For calls to neutron resources. Calls to GP resources can probably be directly on the plugin
18:28:57 <armax> don't we all have reservations about performance and failure modes?
18:28:58 <armax> :)
18:28:59 <SumitNaiksatam> mandeep: ok
18:29:03 <armax> regardless of the approach?
18:29:09 <SumitNaiksatam> armax: true
18:29:31 <SumitNaiksatam> armax: are you comfortable with what mandeep mentions above ^^^ (and rkukura’s placn)?
18:29:38 <SumitNaiksatam> *plan
18:29:52 <rkukura> armax: I think using the client ensures keeping a loose coupling, enables progress, and can easily be revisited later
18:30:05 <armax> SumitNaiksatam: at this point I think that gerrit is best venue to take the discussion forward
18:30:20 <SumitNaiksatam> armax: ok, so we are not doing the ad hoc meeting any more
18:30:29 <armax> having the code side by side with comments is very valuable
18:30:34 <SumitNaiksatam> LouisF: i wil punt that question to hemanthravi
18:31:06 <SumitNaiksatam> LouisF: btw, this discussion the client is different from the client for the GP model
18:31:25 <LouisF> agree
18:31:46 <SumitNaiksatam> LouisF: out here we are talking about accessing the existing neutron resources from the GP mapping driver by using the neutronclient
18:31:49 <SumitNaiksatam> LouisF: okay
18:31:51 <hemanthravi> SumitNaiksatam: this will be using neutronclient to create the net/subnet/port resources and not the gp resources, rihgt?
18:31:59 <SumitNaiksatam> hemanthravi: yes
18:32:34 <SumitNaiksatam> LouisF: does that answer your question, or were you asking the CLI design for the GP model?
18:33:08 <LouisF> yes that answers my question
18:33:13 <SumitNaiksatam> LouisF: good
18:33:16 <rkukura> So is everyone OK with the ImplicitContextDriver making direct calls on the GP plugin to create L2Context and L3Context instances, at least for now?
18:33:39 <SumitNaiksatam> rkukura yes, that was also an item on the agenda
18:33:48 <SumitNaiksatam> rkukura: we discussed this last week
18:33:55 <SumitNaiksatam> rkukura: and good to get agreement
18:34:29 <SumitNaiksatam> rkukura: whats the alternate approach?
18:34:51 <rkukura> Eventually we may decide that quotas need to be enforced on the L2Context and L3Context that get created, which would be done if we used the python-neutronclient with GP support, or used the Controller. But this can come later.
18:35:07 <SumitNaiksatam> rkukura: ah i see
18:35:23 <SumitNaiksatam> rkukura: so similar issue as that with the other neutron resources
18:35:39 <rkukura> Not as critical as the DHCP and nova notifications for ports
18:36:02 <SumitNaiksatam> rkukura: agree, so i am +1 for the approach you mentioned (making direct calls)
18:36:35 <rkukura> OK, this avoids introducing a dependency on an update python-neutronclient, which would prevent merging
18:37:09 <SumitNaiksatam> #agreed calls to neutron networks, ports, subnets, routers from the mapping driver wil be made using the python-neutronclient
18:37:30 <SumitNaiksatam> #agreed calls to GP resources from the mapping driver will be made directly
18:37:42 <SumitNaiksatam> rkukura: sound okay ^^^ ?
18:37:52 <rkukura> yes, at least for now
18:37:57 <SumitNaiksatam> ok
18:38:36 <armax> the two agreement statements seem to be in contradiction
18:38:36 <SumitNaiksatam> so rkukura brought up a good point earlier on whether we need to support both v4 and v6 in the same EPG
18:38:43 <armax> SumitNaiksatam: could you clarify?
18:39:07 <SumitNaiksatam> armax: the first statement is per the earlier discussion (including email threads)
18:39:53 <rkukura> 1st is calls on existing neutron resources, 2nd is calls on GP resources
18:39:54 <SumitNaiksatam> armax: the second statement says, that for the GP resources that need to be created/updated from the mapping driver, the mapping driver will make direct calls on the GP plugin API
18:40:29 <armax> SumitNaiksatam: gotcha, thanks
18:40:57 <armax> SumitNaiksatam: so long as back and forth of messages between objects is minimized we should be good
18:41:11 <SumitNaiksatam> armax: yeah, i agree
18:41:28 <SumitNaiksatam> so back to the earlier point - rkukura brought up a good point earlier on whether we need to support both v4 and v6 in the same EPG
18:41:50 <SumitNaiksatam> i am guessing not for Juno
18:41:54 <SumitNaiksatam> right?
18:42:16 <SumitNaiksatam> if not, rkukura’s question is whether we will ever support
18:42:32 <rkukura> If we aren’t doing IPv6 for Juno, we definitely won’t do both for Juno
18:43:16 <SumitNaiksatam> rkukura: true, but i am not sure if we will ever need it
18:43:23 <SumitNaiksatam> anyone has thoughts on this?
18:43:55 <rkukura> But I’ve got no hands-on IPv6 experience, and was wondering if the model should allow an EPG to have multiple L2Cs and/or an L2C to have multiple L3Cs, either/both of which would allow a single EPG to have both IPv4 and IPv6 L3Cs
18:44:19 <mandeep> SumitNaiksatam: We will probably need a longer design review for IPv6 and GP, I recommend a fuller review post-Juno deliverables and not make this decision without that background
18:44:50 <SumitNaiksatam> mandeep: so in the shorter term how do we make this future proof?
18:45:05 <rkukura> One key question is whether these use cases would be IPv4 and IPv6 subnets on the same network, or on different networks, or both need to be supported
18:45:25 <SumitNaiksatam> ok lets take this offline
18:45:31 <rkukura> Sure
18:45:34 <mandeep> rkukura: SumitNaiksatam: OK
18:45:47 <SumitNaiksatam> #action mandeep rkukura to discuss ipv6 implications
18:46:20 <SumitNaiksatam> we also discussed last week about the “implicit context driver"
18:46:29 <SumitNaiksatam> just want to make sure that we all agreed
18:47:24 <SumitNaiksatam> so this is a dirver which defines the criteria for implicitly creating resources
18:47:26 <mandeep> SumitNaiksatam: You mean the driver split into two parts, correct?
18:47:26 <rkukura> This driver packages the code thats in the mapping_driver in the PoC that creates L2Context (BD) and L3Context (RD) objects when they are not explicity passed into the API
18:47:36 <SumitNaiksatam> rkukura: thanks
18:47:45 <rkukura> mandeep: correct
18:48:11 <mandeep> rkukura: OK, got it. And I agree with that.
18:48:19 <SumitNaiksatam> perhaps this will be more clear when people actually see this in the code
18:48:32 <SumitNaiksatam> so as of now rkukura you are going with that approach, right?
18:48:40 <rkukura> thats the plan
18:48:44 <SumitNaiksatam> rkukura: ok
18:48:45 <SumitNaiksatam> moving on
18:48:47 <SumitNaiksatam> #topic Resource name changes (again!)
18:49:21 <SumitNaiksatam> last week the suggestiong was to rename BD, RD to l2/3_context resp
18:49:42 <SumitNaiksatam> but we already have resource context objects used internally in the code
18:49:53 <SumitNaiksatam> and we end up with names like L2ContextContext
18:50:00 <SumitNaiksatam> rkukura already pointed out that last week
18:50:16 <SumitNaiksatam> so the suggestion is to rename l2/3_context to l2/3_policy
18:50:39 <SumitNaiksatam> everyone okay?
18:50:47 <mandeep> SumitNaiksatam: Ok
18:51:11 <SumitNaiksatam> or i should ask, anyone disagree or any better names?
18:51:38 <SumitNaiksatam> ok sold then!
18:51:58 <SumitNaiksatam> #agreed BD, RD -> l2/3_context -> l2/3_policy
18:52:08 <SumitNaiksatam> #topic API interception/Nova integration
18:52:14 <rkukura> I don’t see a problem with that, but I’m not sure if “implicit policy driver” is better or worse than “implicit context driver”
18:52:27 <SumitNaiksatam> #undo
18:52:28 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x235d750>
18:52:59 <SumitNaiksatam> rkukura: how about implicit mapping driver?
18:53:28 <rkukura> Its not really a mapping, its implicit resource management
18:53:35 <SumitNaiksatam> agree
18:53:37 <mandeep> rkukura: agreed
18:53:50 <SumitNaiksatam> perhaps we can discuss offline, since that is not as critical as resource names
18:54:09 <rkukura> we could rename the Context objects passed to the driver API
18:54:26 <rkukura> Maybe L2CContext, L3CContext, EPGContext, EPContext, …?
18:54:48 <SumitNaiksatam> rkukura: yeah thats a possibility
18:55:20 <SumitNaiksatam> but more importantly, l2/3_policy seemed more natural to this context, than l2/3_context
18:56:06 <SumitNaiksatam> #action rkukura to suggest renaming of implicit context driver
18:56:14 <SumitNaiksatam> #topic API interception/Nova integration
18:56:31 <SumitNaiksatam> we discussed this just a bit last weel
18:56:34 <SumitNaiksatam> *week
18:56:51 <SumitNaiksatam> hoping to get more time this week, but i think we are running behind again
18:57:17 <SumitNaiksatam> so the issue here is that we need to intercept the port creation calls from nova
18:57:30 <SumitNaiksatam> we can revisit this next week
18:57:36 <SumitNaiksatam> #topic Open Discussion
18:58:12 <SumitNaiksatam> did we miss anything?
18:58:20 <rkukura> lets put testing on the agenda for next week
18:58:41 <SumitNaiksatam> rkukura: yeah, i was just going to say, we wanted to discuss functional tests as well
18:58:56 <SumitNaiksatam> perhaps people need to say a little more of the code to get a better context
18:59:15 <SumitNaiksatam> i guess we should be in good shape on that front next week
18:59:30 <SumitNaiksatam> anything else?
18:59:47 <rkukura> For the mapping driver patches, I’d like to try to stick to pure unit tests, and do the testing we have in the PoC as functional tests
19:00:03 <SumitNaiksatam> rkukura: +1
19:00:27 <rkukura> So these unit tests would mock the neutron-pythonclient calls
19:00:31 <mandeep> rkukura: Let us review that with Maru as well
19:00:42 <rkukura> and neutron resources would not actually get created
19:00:42 <mandeep> rkukura: He had some specific feedback on functional tests
19:00:51 <SumitNaiksatam> ok, on that happy note, lets wrap for today
19:00:55 <SumitNaiksatam> #endmeeting