18:01:50 #startmeeting networking_policy 18:01:51 Meeting started Thu Jul 10 18:01:50 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:51 SumitNaiksatam: Hi 18:01:52 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:01:54 The meeting name has been set to 'networking_policy' 18:02:18 #info agenda: https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy#July_10th.2C_2014 18:02:33 #announcements Juno specification submission deadline: July 10th, specification approval deadline: july 17th 18:03:43 hi - sorry I’m late 18:04:07 rkukura: Hi 18:04:15 i believe we got a few more related specs in to beat the deadline 18:04:20 rkukura: hi 18:04:46 #topic Patches in review 18:04:47 SumitNaiksatam: Oh? I thought our spec has already been approved? 18:04:53 #link https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy/Patches 18:05:03 s3wong: i meant a few other specs 18:05:24 s3wong: some vendor specs, and kevinbenton posted a spec for the API intercept as well 18:05:33 OK 18:05:34 we will discuss those later in the agenda 18:05:35 s3wong: Specs for InterceptAPI, ODL driver, and vendor drivers 18:05:50 just wanted to callout earlier that if something more is being planned, it should land today 18:06:18 i moved the links to the patches to a different page, and i am in the process of organizing the content 18:06:51 so that its easier for the people who are reviewing to understand what each series is doing and what are the dependencies 18:07:18 feel free to update that page once i have the content in there 18:07:24 i mean more content 18:07:37 #topic Resource Model/API/DB/Plugin Update 18:08:01 got some more reviews comments before the july4th break, and have responded to all of them 18:08:40 no negative comments on the first series, except the -2 from markmcclain which was for the missing driver patches 18:08:54 SumitNaiksatam: Thanks for that. That now gives us enough of a model to base the new GBP drivers on 18:08:55 the driver patches have landed, so we expect markmcclain will remove the -2 18:09:03 mandeep__: sure 18:09:04 I spoke with markmcclain about this a little while ago 18:09:10 rkukura: great, thanks 18:09:38 He does feel we should get gpm-rmd-1 out of WIP state before we start merging the series 18:10:15 He’d also like to see some sort of tempest-like functional test that verifies datapath connectivity. 18:10:21 rkukura: okay 18:10:57 rkukura: okay lets get back to the first part, when we discuss your mapping driver update 18:11:07 yeah a working driver and some kind of testing ensures we're not merging broken code 18:11:17 markmcclain: agree 18:11:25 And we do need the DB migrations in each patch that adds/modifies DB model clases 18:11:35 rkukura: +1 that is req 18:11:44 rkukura: yes, db migration is pending 18:11:56 rkukura markmcclain: however that is mechanical 18:12:08 i will be happy to add it right away, if we are close to that stage 18:12:45 if we agree that we are past the initial churn on the DB model, i am happy to add the db migration, right away 18:12:52 do we agree? 18:12:52 I’d really like to get any remaining reviewer input into the first few patches, but am concerned the -2 is hindering that 18:13:02 rkukura: i agree 18:13:48 I can get an updated gpm-rmd-1 patch out by Monday, maybe sooner, but also need to review a bunch of specs 18:14:12 okay, so i think there is silent agreement that the DB model on the first series (EP, EPG, L2/3 Policy) is stable 18:14:19 so i will add the migration script 18:14:38 #action SumitNaiksatam to add DB migration script to first series of GP resources 18:14:50 Does anyone want to volunteer to write a functional test that could later become a tempest test (in K, after API compatability is required)? 18:15:10 SumitNaiksatam: For downstream drivers, we have to assume that the model is reasonably stable to started on that development. 18:15:20 mandeep__: okay 18:15:36 rkukura: i believe rudra rugge wanted to do that 18:15:43 rkukura: we can ping him 18:16:03 SumitNaiksatam: Yes, Rudra had wanted to tackle that during the summit 18:16:18 This may be needed before anything can merge, so we need some commitment 18:16:30 rkukura: i agree with the approach though, i think we can add the functional test right away, and that will ensure sanity of the patches 18:16:44 It should be doable based on the current gmp-rmd-1 patch and its dependencies. 18:17:06 markmcclain: does that sound good? ^^^ (add funcational test to neutron for testing the sanity of the first series)? 18:17:31 *functional 18:17:44 * markmcclain catches up 18:18:35 SumitNaiksatam: did you add that diagram on the mapping driver 18:18:45 SumitNaiksatam: That makes sense if we all agree that the model looks good and that we are waiting for tests to validate that we have end-to-end correctness. It would not make sense if there was any disagreement on the model. So I assume that we are all agreeing on the model. 18:19:02 SumitNaiksatam: looks good 18:19:12 mandeep__: i think we have agreement on that right, from the spec? 18:19:14 markmcclain: thanks 18:19:23 LouisF: sorry, i dont have that yet, i will add 18:19:33 SumitNaiksatam: Yes, you are right. 18:19:40 thx 18:20:05 #action SumitNaiksatam to add diagram fo explain the different functional blocks in the GP stack 18:20:24 forgot to mention something regarding gpm-rmd-1 18:20:29 #action GP team to add functional test(s) to neutron to aid in merging of the first series of patches 18:20:41 rkukura: can you hold that, till we change the topic? 18:20:45 markmcclain and I discussed the various approaches for invoking other plugins 18:20:51 rkukura: separate agenda item for mapping driver 18:20:55 ok 18:21:19 in fact i will change that right away, if nothing else to discuss on the API/Resource model 18:22:25 #agreed Fair level of consensus (or no immediate dissents) on the API/DB model for GP-API/EB/PLG-1 patches, such that functional tests can be attempted using the mapping driver available 18:22:46 #topic Mapping Model/Driver Update 18:22:52 rkukura: sorry, go ahead 18:23:07 ok 18:23:49 so markmcclain also has concerns similar to mine regarding using python-neutronclient for invoking the other plugins 18:24:12 rkukura: okay, i had those earlier as well 18:24:32 in particular, the fact that invocation chains could crisscross between different neutron-server replicas could be a problem 18:24:33 * regXboi running late agan :( 18:24:42 rkukura: OK - are we thinking of NOT using python-neutronclient now? 18:24:53 and the UT issues I had hit are real 18:25:44 rkukura: Yes, we had the same concern earlier, but my understanding was that armax had specific feedback to use python-neutronclient. Did you get an opportunity to discuss with him? 18:25:48 markmcclain described his ongoing work on refactoring the WSGI->Controller-plugin front-end 18:26:45 rkukura markmcclain: i believe that work is not planned for Juno right? 18:26:47 It sounds like markmcclain’s refactoring will provide an ideal interface for our long-term use 18:26:57 He is working to get this in for juno 18:27:05 But we cannot depend on it merging first 18:27:10 rkukura: agree 18:27:15 rkukura: agreed 18:27:23 I am getting up to speed with the latest developement 18:27:37 rkukura: in the interim, i think direct calls, provide a reasonable path forward 18:27:39 I know that rkukura and markmcclain chatted about this but I don’t know the specifics 18:27:40 So we agreed sticking with the current approach is best for the interim 18:28:01 I’ll touch base with people offline 18:28:02 rkukura: thats seems very logical and reasonable to me 18:28:13 rkukura: Can you review it with armax as well? 18:28:39 markmcclain told me he is willing to disucss this with armax if needed - we all agree its not ideal long term due to possible divergence between the real Controller and our version, but it should suffice 18:28:50 rkukura: i believe with that, the gp-rmd-1 patch can come out of WIP right away? 18:29:09 rkukura: OK 18:29:25 rkukura: so with the current approach, we are still going with python-neutronclient? 18:29:31 I need to add code to handle updates, keep track of whether mapped resources are owned, and cleanup owned resources when GP resources are deletted 18:29:39 rkukura: okay 18:29:51 this will all follow patterns already in the implciit_policy driver 18:29:59 s3wong: in our current approach we dont use the python-neutronclient 18:30:25 s3wong: as deteremined by rkukura, and validated by markmcclain, using the python-neutronclient does not seem a good option at this point 18:30:52 SumitNaiksatam: so we are going with direct calls (as in PoC)? 18:30:52 SumitNaiksatam: what are the alternatives here? 18:31:01 So do we all agree our current plan is to stick with the direct plugin calls, with code to invoke notifiers, etc., until the WSGI front end refactoring provides a better solution? 18:31:28 s3wong: as is in the current patch: https://review.openstack.org/#/c/105272 18:31:35 s3wong: As in the latest patch ... that is an update from the implementation in the PoC 18:32:17 LouisF: Direct calls to Controller Object vs. using pyhton-neutronclient API 18:32:21 LouisF: we have only two alternatives, make direct calls (since we are in the same process space), or use the python-neutronclient library (though we are in the same process space) 18:32:44 LouisF: but rkukura determined that the later is not feasible for more than one reason 18:33:33 we also discussed using the Controller instances, but there is no way to do that currently, and markmcclain doesn’t want to enable this because code depending on this would have to change as the front end is refactored 18:33:35 LouisF: eventually, there is a plan to refactor the current WSGI framework, such that it will be easier to route these calls, and GP will make use of that 18:33:50 rkukura: okay 18:33:52 markmcclain: Please let me know if I’m misrepresenting any of what you said 18:34:04 SumitNaiksatam: ok 18:34:36 rkukura: you've accurately recreated the convo :) 18:34:38 The initial front end refactoring will not break the way we are currently doing the direct plugin calls 18:34:57 so... if we aren't using neutronclient, what about horizon or HEAR? 18:34:59 er HEAT? 18:35:07 rkukura markmcclain: nice! 18:35:14 regXboi: They should continue to use neutronclient 18:35:31 regXboi: as rkukura said they will 18:35:31 They are separate processes, with seperate test environments 18:35:45 regXboi: what we are discussing here are the internal calls 18:36:22 regXboi: The issues was in calling python-neutronclient from a driver 18:36:26 regXboi: the calls which the group policy mapping driver makes to the neutron core plugin to create the “traditional” neutron resources, once the mapping from the group policy resource to the neutron resource is established 18:36:35 got it 18:36:43 I was reading it the other way round 18:36:47 regXboi: you would be excused for wondering why one would the python-neutronclient for this :-) 18:37:14 well that was going to be my next question, yes :) 18:37:17 regXboi: the CLI and client the GP resources is as planned 18:37:42 *for the GP resources 18:37:44 SumitNaiksatam: thx ... 18:37:55 ok anything else for rkukura? 18:38:10 Anyway, given the above, I’m hopefully we can get the gp-api-1 -> gpm-rmd-1 stream of patches merging next week 18:38:17 this may not fit here 18:38:22 rkukura: amen! 18:38:28 regXboi: go ahead 18:38:34 especially if we can get rudra to submit a functional test 18:38:39 but do we have patches for the CLI and client changes? ( I may have missed them) 18:38:55 regXboi: yes we do, and we have a separate agenda item as well 18:39:04 ok, I'll be quiet then :) 18:39:06 regXboi: all patches linked from: https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy/Patches 18:39:16 regXboi: see CLI and horizon at teh bottom of that page 18:39:23 SumitNaiksatam: also horizon work 18:39:25 yep... got it 18:39:29 LouisF: yes 18:39:48 LouisF: WIP patch was posted, and we do have a separate agenda item 18:40:00 rkukura: thanks for the update, any blockers for you? 18:40:17 nothing other than needing to do a lot of spec review before the deadline for those 18:40:24 rkukura: :-) 18:40:36 #topic Security Groups mapping update 18:40:41 s3wong: hi 18:40:44 hello 18:41:07 So I have updated the google doc to reflect on preliminary idea on how to map to SG 18:41:17 #link https://docs.google.com/document/d/134P7TJdiIfjPWbmstSTY4vp9E6oRYTFs64ON3thFxhI/edit# 18:41:46 please comment (mostly the last section: "Contract Rendering Workflow") 18:42:18 s3wong: I’ll read/comment the doc, but is the current plan to use one SG per EPG? 18:42:38 rkukura: one SG per contract providing EPG 18:42:42 rkukura: i was thinking more on this 18:42:58 rkukura s3wong: i think we probably need on SG per EPG for the default rules 18:43:07 rkukura: SG created when both consuming and providing EPGs are known 18:43:09 and then one SG per Contract 18:43:35 i had not realized earlier that you can associate multiple SGs with a neutron port, but you can 18:43:49 I think we should create the SG at the same time we create the EPG, and set that SG on all EPs within that EPG 18:43:51 SumitNaiksatam: yes, I found out about that recently as well 18:43:59 with that, i believe the above mapping would wor 18:44:01 *wrok 18:44:05 SumitNaiksatam: +1 18:44:17 Then just add/modifiy/delete rules within it as contracts/policies/rules change 18:44:23 but i am not what is the order in that case 18:45:09 Oh, I misssed the multiple SGs thing 18:45:19 i mean to say i dont what how the SGs are ordered when more than one SG is associated with a neutron port 18:45:37 fyi - #link http://docs.openstack.org/admin-guide-cloud/content/securitygroup_workflow.html 18:45:39 So the API allows it, but are the semantics defined? 18:45:49 rkukura: not sure 18:45:53 rkukura: need to check the code 18:46:03 s3wong: any chance you got to explore that? 18:46:30 SumitNaiksatam: I saw that the API allows multiple SGs to be associated per port 18:46:46 s3wong: yeah, i guess we need to try this out 18:46:58 SumitNaiksatam: agreed 18:47:32 * regXboi suspects that the implementation doesn't care about priority 18:47:32 SumitNaiksatam: rkukura: but in any case, the CIDR field would allow us to ensure applying appropriate rules to traffic flow, right? 18:47:55 If multiple SGs/port helps, great. But is there any reason we can’t make it work with one SG (per EPG) if needed? 18:47:58 regXboi: yeah, probably, so its messy 18:48:24 rkukura: we can make it work with one SG per EPG as well 18:48:35 rkukura: but then we have to preserve more mapping 18:48:37 SumitNaiksatam: unless you want to know which SG is matched, then I don't think it is 18:48:39 rkukura: It would make thde code (and it's updates) much cleaner with one SG per contract (and multiple per port) 18:48:43 I guess if the default rule is deny, and any SG on the port can allow, we might be able to use this 18:48:51 but of course, we would like to know which SG is matched :) 18:49:50 rkukura: You have a point ... the white-list approach handles the ordering issues 18:50:02 s3wong: i did not quite understand your question, i am still processing :-( 18:50:07 um... 18:50:21 Aren't neutron SGs whitelists by definition? 18:50:29 regXboi: yes 18:50:30 regXboi: yes they are 18:50:46 regXboi: As are GBP rules 18:50:55 ok - rkukura confused me for a second 18:51:11 oh shoot, we have only 10 mins left in the meeting! 18:51:29 s3wong: thanks for spending time and leading this 18:51:36 SumitNaiksatam: port w/ SG with rules XYZ && CIDR 10.0.1.0/24 and rules ABC && CIDR 10.0.2.0/24 18:51:41 s3wong: i believe we need some more offline discussions on this 18:51:56 s3wong: ok i will respond to your email thread, thanks! 18:52:01 SumitNaiksatam: cool 18:52:04 s3wong: thanks for the update 18:52:25 #topic API Intercept 18:52:48 kevinbenton: posted a spec for this: https://review.openstack.org/#/c/105695/ 18:52:55 kevinbenton: thanks much for the quick turnaround 18:53:09 banix is also working on this 18:53:38 this will allow us to get over the current limitation of not being able to support GP API and traditional Neutron API simultaneously 18:53:45 I suggest talking with markmcclain about how the refactored front end will support this 18:54:09 rkukura: what do you mean by the front-end in this case? 18:54:13 rkukura: i am sure the new refactoring will have a way to do this 18:54:17 even if we need an interim solution 18:54:32 rkukura: we are trying to work through an intermediate approach 18:54:53 markmcclain and I touched on this in our conversation, and it sounds like he has a specific solution in mind 18:55:42 rkukura: I believe that kevinbenton and banix are at the mid-session summit with markmcclain 18:55:48 rkukura markmcclain: is there a spec/document that kevinbenton can look at? 18:55:56 mandeep__: yes on banix 18:56:07 banix is here, but not kevinbenton 18:56:08 * regXboi was supposed to be there but had to cancel :( 18:56:09 kevinbenton could not make it 18:56:21 SumitNaiksatam: i am :-) 18:56:28 * mandeep__ Ooops 18:56:34 kevinbenton: oh you made it? :-) 18:56:40 SumitNaiksatam: whoops. i am in this meeting 18:56:42 markmcclain will be submiting a spec today, but it will be mostly placeholder 18:56:43 not in MN 18:56:45 kevinbenton: yeah :-) 18:57:40 rkukura markmcclain kevinbenton: hopefully we will have a path forward on this, whichever is the most feasible (short and long term) 18:57:55 kevinbenton: thanks much! 18:57:59 SumitNaiksatam: +1 18:58:03 #topic Vendor drivers 18:58:18 its great to see that a bunch of vendor drivers specs have been submitted 18:58:36 we actually 5 GP driver submissions including ODL! 18:58:42 SumitNaiksatam: +1 18:59:14 thanks all, and the dependency is really on the base model patches to merge 18:59:17 SumitNaiksatam: links to these? 18:59:20 #topic Open Discussion 18:59:25 LouisF: they are in the agenda 18:59:29 regXboi: go for it 18:59:39 so... revenge of multicast classifier 18:59:47 regXboi: :-) 19:00:03 we really need a multicast policy classifier 19:00:14 the SDN-VE driver is going to use it 19:00:27 * SumitNaiksatam thinks we can stay in this meeting until we are kicked out (being optimistic that we are not) 19:00:36 because we have use cases around giving different policy to multicast traffic 19:00:53 regXboi: okay 19:00:54 LouisF: Look under "Vendor/Open Source Controller Drivers". There are 5 backends proposed - ODL, Cisco, One Convergence, Nuage, and IBM 19:01:05 I'd like something very simple in the policyclassifier 19:01:13 and leave it to the drivers to do the necessary low level magic 19:01:21 is that possible? 19:01:21 regXboi: Did you want to write that up a BP? 19:01:28 today? 19:01:33 * regXboi goes ouch 19:01:40 regXboi: one of the approaches could be to use resource extension 19:01:49 That way, it's implementation in the reference implementation does not become an issue 19:01:54 regXboi: it could be made part of the IBM SDN-VE bp spec 19:02:13 SumitNaiksatam: I'll get with banix on that approach 19:02:20 SumitNaiksatam: Yes, that can done as a resource extension. Good point 19:02:22 because that looks to be the best way forward 19:02:29 regXboi: so we would be creating a new extended policy classifier resource which adds the multicast field 19:02:43 SumitNaiksatam: something like that, yes 19:02:57 regXboi: once we have enough consensus, we can promote that attribute to the policy classifier itself 19:03:22 I think that will work for me 19:03:25 regXboi: but at least for the time being it will unblock the IBM driver, and will provide it with a way to use it 19:03:25 regXboi: (Sorry, I know that the BP deadline being today) 19:03:51 since the SDN-VE bp spec is already there, we can piggyback 19:04:00 so I don't need to write a *new* bp 19:04:02 regXboi: exactly 19:04:08 regXboi: ;-) 19:04:10 regXboi: thats my thinking 19:04:13 and that was my concern, given folks are in MN 19:04:24 * regXboi notes "great minds...." 19:04:28 regXboi: understand 19:04:36 any other questions/thoughts/comments? 19:04:42 ok, that works for me - thanks! 19:04:45 and I'm good :) 19:04:51 +1 19:04:54 regarding CLI/client 19:04:58 songole: there? 19:05:07 anything blocked at your end? 19:05:17 SumitNaiksatam: No. 19:05:26 I am starting on the 2nd patch set 19:05:29 * regXboi pads away to discuss "cow" things 19:05:33 ah, just typing that :-) 19:05:52 you can start with the other resources as well (easy for me to say :-P) 19:05:59 is ronak here? 19:06:15 i was hoping to get a Horizon update 19:06:47 #action SumitNaiksatam to ping Ronak on the state of Horixon 19:06:57 I meant 2nd API set for other resources.. 19:07:08 songole: yes, thats what i meant 19:07:32 ok 19:07:32 anything else that we need to discuss since we have not yet been kicked out? 19:08:04 alrighty, thanks everyone! 19:08:08 thanks 19:08:10 #endmeeting