18:07:08 #startmeeting networking_policy 18:07:09 Meeting started Thu Sep 11 18:07:08 2014 UTC and is due to finish in 60 minutes. The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:07:10 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:07:12 The meeting name has been set to 'networking_policy' 18:07:16 apologies for the delay in starting! 18:07:26 np 18:07:26 #info agenda: https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy 18:07:35 SumitNaiksatam: may want to make banix chair too in case you drop out :-) 18:07:41 yes yes 18:08:05 #chairs banix s3wong rkukura_ rms_13 ivar-lazzaro LouisF 18:08:22 there, thanks for reminding s3wong :-) 18:08:30 #topic Status update 18:08:49 so we are going through a process of validating the patches that we have posted 18:08:56 let me start with ivar-lazzaro 18:09:08 SumitNaiksatam: yup 18:09:11 he has been spending quite a bit of time with testing the data path 18:09:16 ivar-lazzaro: thanks for jumping in 18:09:28 ivar-lazzaro: go ahead, cna you please update us with your findings? 18:09:29 ivar-lazzaro: yes, thank you 18:09:42 SumitNaiksatam, s3wong: no problems 18:09:43 s3wong: thanks for bringing up up to speed as well 18:10:02 I've just pushed a rebase on the whole GBP series, together with some fixes in the DB migration 18:10:27 and some changes in how SGs are mapped through contracts 18:10:31 ivar-lazzaro: nice 18:10:39 ivar-lazzaro: and you had some success with the testing? 18:10:42 The validation is going well so far, I'm able to get traffic for simple setup 18:10:48 ivar-lazzaro: nice 18:10:52 ivar-lazzaro: great! 18:11:03 So everything smooth so far :) 18:11:21 ivar-lazzaro: that’s in part thanks to your effort! ;-) 18:11:41 ivar-lazzaro: you were also making a point about using remote SG ids in the SG mapping? 18:12:01 SumitNaiksatam: correct 18:12:26 So looking at the implementation, I'm afraid we could get into some troubles when overlapping IPs are enabled 18:12:34 ivar-lazzaro: right, I briefly looked at the changes, seems like you are still using CIDR/remote-ip-prefix? 18:12:51 which means that some EPGs might be able to reach others even without sharing the same contract 18:13:09 s3wong: yes, I want to know what the rest of the team thinks 18:13:22 s3wong: before going that route 18:13:34 ivar-lazzaro: can you post the link to the updated version please 18:13:39 Overlapping IPs of different tenants that are completely isolated from each other should be OK 18:13:40 ivar-lazzaro: I have no objection - it actually will simplify the implementation a bit 18:13:53 s3wong: you mentioned that you had discussed this with rkukura_? 18:13:55 banix: searching 18:14:02 banix: the patch series is updated 18:14:20 banix: #link https://review.openstack.org/#/c/113775/ 18:14:25 ivar-lazzaro: thanks 18:14:30 SumitNaiksatam: rkukura_: yes. rkukura_ -- if you remember, during the hackathon, we visited the remote-SG option, but we opted not to go with it 18:14:40 rkukura_: but I don't remember the reason... do you? 18:15:06 I had concerns 18:15:11 rkukura_: well in theory, as long as you are using a different l3_context you can have overlapping subnets right? 18:15:15 My concerns were mainly about efficiency 18:16:02 If using SG IDs means there is a separate iptables rule for each IP addr rather than for each subnet, then it will not scale well 18:16:03 rkukura_: can you expand on that? 18:16:57 rkukura_: ah, so you wanted to avoid the remote SG since the SG implementation maps that to specific iptables rules 18:17:26 rkukura_: whereas we could be more intelligent in the way we craft the CIDRs and reduce the number of rules 18:17:28 I don’t see how the SG implementation could know how GBP is using subnets, and that matching the prefix is a valid optimization 18:17:37 rules -> iptables rules 18:17:38 right 18:18:10 The whole reason we are mapping EPGs to one or more subnets is to enable this optimization 18:18:19 rkukura_: makes sense 18:18:33 rkukura_: ivar-lazzaro is treating the SG implementation as blackbox 18:18:35 rkukura_: thanks! those are all valid points 18:19:15 rkukura_: and if we assume that the SG mapping/implementation is optimal, then using remote SG makes it much more easier to maintain consistency 18:19:40 rkukura_: but perhaps the assumption is not correct from an optimality perspective 18:19:44 But the SG implementation cannot know that all IPs in a subnet will be treated the same! 18:19:52 rkukura_: ok 18:20:06 ivar-lazzaro: lets think about it more 18:20:19 We are also going to need ways to treat external subnets as EPGs, right? 18:20:20 rkukura_: ivar-lazzaro: SumitNaiksatam: consensus then? Going with current implementation? 18:20:22 and discuss with rkukura_ and s3wong 18:20:31 SumitNaiksatam: OK 18:20:40 s3wong: i dont think ivar-lazzaro has changed that part of the implementation yet 18:21:02 SumitNaiksatam: yeah, I was also concerned on how many new rules you have to add to the existing SGs when a new subnet is added to an EPG 18:21:22 SumitNaiksatam: yes, I know. Just wanting to get to a decision point :-) 18:21:29 s3wong: :-) 18:21:33 SumitNaiksatam: which would come for free with the remote SG. But I agree that we need to look for the most scalable solution 18:21:49 I think we can tune the subnet size to avoid scaling issues, especially with private address spaces 18:22:01 ivar-lazzaro: yeah, i think this requires more discussion than the short time available here 18:22:14 ivar-lazzaro: yes - and I have not implemented that in update_epg (with a TODO :-) ) 18:22:18 ivar-lazzaro: thanks for the update 18:22:28 SumitNaiksatam: agree! 18:22:34 i dont think there is any update on the model side from me, or from rkukura_ on the mapping 18:22:44 s3wong: TODO is the same as being already there :p 18:22:54 s3wong: and ivar-lazzaro are collaborating on validating the SG mapping 18:22:57 as we just discussed 18:23:20 the CLI is being tested as we are validating this 18:23:42 and ivar-lazzaro found an issue with clearing the “provided/consumed” contracts dict in the EPG 18:23:51 so that needs to be fixed 18:23:59 i believe songole is working on it as we fix 18:24:11 SumitNaiksatam: great! 18:24:15 other than that CLI is operational to the extent we have tested it 18:24:30 rms_13: Horizon :-) 18:24:36 Yes 18:24:55 Working on your complain about horizon not starting :) 18:25:02 Should have update in 1 hr 18:25:18 rms_13: sweet, it was not a complain, just an observation! ;-P 18:25:33 My VM with new code just came up so looking into it...may be I will have answer towards end of this meeting.... 18:25:42 rms_13: awesome 18:25:49 yeah.. no worries...will be fixed 18:26:04 rms_13: i know you are swamped with other things on your plate as well 18:26:12 rms_13: so thanks for doing this for the team! 18:26:26 SumitNaiksatam: happy to be part 18:26:45 i am not sure if susant is here 18:27:03 i believe he updated the Heat patch as well, but i am not sure how complete that is 18:27:54 oh it seems like he posted a second patch: #link https://review.openstack.org/#/c/120862/ 18:28:07 LouisF: i know you were interested in tracking this ^^^ 18:28:24 the first patch was #link https://review.openstack.org/#/c/111419/3 18:28:45 everything is still documented in our wiki page: https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy/Patches 18:29:11 yes 18:29:43 will review 18:29:46 i have not tested the Heat part, perhaps LouisF you can help? 18:29:56 ok 18:31:12 btw, if someone wants to run devstack pointing to the above branches, the following local.conf might work 18:31:18 #link https://gist.github.com/snaiksat/0ce525f8f57f84574793 18:31:40 you might need to update the patch references and the patch set numbers 18:31:51 LouisF: the above might help if you are testing Heat 18:32:28 any other updates we want to cover in terms of the current implementation? 18:32:47 thx 18:33:04 #topic Next steps discussion 18:33:56 based on the feedback in the ML over the past week, it seemed like the stackforge repo is needed regardless of which direction we tak 18:33:59 *take 18:34:15 so we do have the stackforge repo now: #link http://lists.openstack.org/pipermail/openstack-dev/2014-September/045423.html 18:34:37 we do have repos for the client and the specs as well 18:34:52 there is more discussion going on the same thread 18:35:07 SumitNaiksatam: nice! Thanks for working on this 18:35:27 there was an email from rkukura_ earlier today and some follow up from kevinbenton mandeep and s3wong 18:35:59 yes, basically a last ditch effort to avoid stackforge 18:36:04 rkukura_: okay 18:36:43 but I agree with others that if the community isn’t ready to invest reviewer cycles in GBP, there isn’t another option 18:36:46 rkukura_: i would interpret as a last ditch effort to keep the other options alive 18:37:20 rkukura_: it seems like for us to be able to experiment we would always need the flexibility of stackforge in parallel 18:37:27 rkukura_: what are your main concerns about stackforge? 18:37:39 I’m not convinced there is any reasonable possibility to move significant code developed outside the neutron repo into the neutron repo. 18:37:54 LouisF: staying there for good 18:38:39 rkukura_: banix: can we not introduce the features that are in stackforge into the feature branch or the incubator? 18:39:34 I think we’d need to tear it apart into reviewable patches, which is a huge effort, and we’d likely have to make design changes as we go. 18:39:50 SumitNaiksatam: yes, that would be essentially using other options. 18:39:56 Reviews would want changes, would effect all the subsequent patches. 18:40:29 So it would basically be a re-implementation in the neutron repo. 18:40:35 rkukura_: but it seems that we would have to follow that approach regardless 18:41:00 rkukura_: that is one long email :) ned to read carefully after the call 18:41:15 I was hoping we’d find a way to get the code reviewed as we develop it, rather than after its all done. 18:41:33 rkukura_: we are already one with the code :-) 18:41:37 banix: I abandoned at much longer version 18:41:45 rkukura_: at least a major part of it 18:42:12 SumitNaiksatam: You have a point, but at least its a series of patches that have already been through substantial review 18:42:20 at least some of them 18:42:28 rkukura_: true 18:43:00 if we take them to stackforge and then try to bring them back, we’ll be starting over on the reviews, and may need to split it into API subsets again, etc. 18:43:22 rkukura_: well I think that the main point here is to try to get as many people as possible using it, In order to validate the model and gain consensus 18:43:26 rkukura_: agree 18:43:37 rkukura_: hopefully the quality of the code matters 18:43:51 ivar-lazzaro: I can’t disagree with that, and stackforge may be the only workable short term option 18:43:54 rkukura_: that certainly doesn't come without a merging effort, but it may happen in the neutron incubator as well after the details are set 18:44:19 rkukura_: if its been baked, then we can hope that it will be a shorter review cycle 18:44:33 I think the fundemental question is whether the neutorn community wants to devote core review time at this point 18:45:03 SumitNaiksatam: We can hope, but the “I’d have done it differently” syndrome scares me. 18:45:06 rkukura_: yes, i think that is one of the fundamental questions 18:45:27 i think what we need to revsist is how we bring in the rest of the community, that is the rest of the cores. not necessarily agreeing on having GBP but as what the process should be to see if we can get there 18:46:03 banix: those two see to go hand in hand 18:46:25 banix: agreeing on how to get a feature into neutron, would depend on whether there is belief in the feature 18:46:46 banix: I think that part of that effort is having an implementation that people can use, so that we can get feedback on it 18:46:46 banix: if there isnt belief, then the process probably does not work 18:46:55 banix: as we have realized in the last cycle 18:46:57 SumitNaiksatam: exactly 18:47:10 banix: i think the process was followed, and no one disputed that 18:47:36 SumitNaiksatam: I think what we heard at least from some was we are not convinced but we are open to explore; in that spirit we should engage them 18:48:08 but i believe the feedback was that people need to use this and tell us that this is useful 18:48:40 +1 18:48:55 banix: true 18:49:23 SumitNaiksatam: yes that was part of it as well. so the question is if with going through StackForge we may cover that usage part a bit better but lose in other fronts 18:49:23 banix: hence i think it behooves us to give those people something that they can use and explore 18:50:02 ODL is moving ahead with a GBP implementation - does that indicate that there is significant interest? 18:50:04 I agree that we might get to the point in which the merging effort would become great… But that may be well spent time as long as we have a broader consensus that the feature is cool and that it should be into Neutron 18:50:06 SumitNaiksatam: sure; all i am saying is we should continue engaging Neutron and follow up on incubator/feature branch options 18:50:55 banix: yeah, at least my point is that the stackforge option is not necessarily mutually exclusive 18:51:07 banix: or for that matter any option 18:51:07 banix: agree, those options are always open 18:51:37 LouisF: good point, but i am not sure its ready, and/or when it will be 18:51:49 SumitNaiksatam: yes, i think we can make it that way; will require us having that mind set 18:51:50 LouisF: so it might not be an immediate data point that can be used here 18:52:38 stackforge is also an option to explore 18:53:17 so we will hopefully get better understanding from having something working, and the feedback we gain that be used in how we make progress 18:54:19 currently we are bit constrained on the technical options 18:54:37 anyway, we are getting close to the hour 18:54:49 I don’t see any reason we shouldn’t move forward immediately on figuring out exactly how we’d structure things in stackforge. If this seems reasonable and its not looking like any better option is going to be available, then we should merge the patches into stackforge and iterate there. 18:55:08 rkukura_: okay 18:55:23 SumitNaiksatam: agree 18:56:13 so lets start thinking in terms of what the stackforge structure would look like 18:56:32 we probably dont have enough time to discuss in this meeting 18:56:55 one of the imperatives there is that we do need to be able to package this with Juno 18:57:02 so that we can reach the users at the earliest 18:57:10 +1 18:57:11 so we need to factor that in 18:57:21 btw, the above was more like an open discussion 18:57:31 so we will not have a separate agend topic for that 18:57:49 but if anyone has any other point/issue to raise, please feel free to do so 18:57:59 we still have 3 mins ;-P 18:58:58 s3wong: can you elaborate on remote SG? 18:59:23 LouisF: it might take a little longer 18:59:29 LouisF: would a follow up email work? 18:59:34 ok 18:59:35 Is our goal in stack forge to deliver an add-on GBP service plugin on top of both the stable/juno and master neutron branches? 18:59:51 rkukura_: i guess thats open for discussion 19:00:03 along with the client, horizon, heat, etc support? 19:00:03 rkukura_: i mean we at least need stable/juno 19:00:09 rkukura_: the latter yes 19:00:18 rkukura_: but we cannot wait for stable/juno to be cut 19:00:32 we’d start with juno-rc1 I’d think 19:00:41 rkukura_: why not J3? 19:01:00 either way, depending on timing 19:02:00 we are over time 19:02:09 rkukura_: lets follow up on that 19:02:14 anything else? 19:02:31 thanks all 19:02:44 okay, thanks everyone for joining! 19:02:47 bye 19:02:47 #endmeeting