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