18:02:42 #startmeeting networking_policy 18:02:43 Meeting started Thu Jun 26 18:02:42 2014 UTC and is due to finish in 60 minutes. The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:02:44 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:02:46 The meeting name has been set to 'networking_policy' 18:02:54 #info agenda: https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy 18:03:19 #topic API/Resource Model patches 18:03:45 so as in the past week, there was decent amount of review acitvity on these patches 18:04:15 btw, for the links to all the patches see: #link https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy#June_26.2C_19.2C_12.2C_2014 18:04:23 had been planning to put the above in a wiki page 18:04:45 i still need to respond to HenryG and enikanorov’s comments on the DB patch, but nothing major there 18:05:07 other than that, the API patch for the classifier, actions and rules was also posted: 18:05:18 #link https://review.openstack.org/#/c/101816 18:05:29 SumitNaiksatam: Should I wait for you to update the gp-*-1 patches before rebasing mine? 18:05:58 rkukura: if you can that will be good, i will try to do it asap after the meeting (my plan was to have done that yesterday itself) 18:06:07 rkukura: i will drop you a note as soon as i am done 18:06:17 OK, want to minimize churn, so I’ll wait 18:06:23 rkukura: ok cool 18:06:40 thats pretty much my update, open to questions/comments 18:07:36 if no questions then we can move to the mapping update 18:07:52 #topic Mapping api/driver/data path patches 18:08:03 rkukura: over to you 18:08:28 I’m on PTO yesterday through next Wednesday (7/2), but am trying to finish up the two driver patches 18:08:50 rkukura: i updated the agenda with the links to the patches 18:08:54 I’ll rebase the exisitng patches on SumitNaiksatam’s upcoming update, and post those today 18:09:07 rkukura: when an EPG is created, does a network and subnet also get created? 18:09:11 I hope to have the implicit policy driver patch posted today 18:09:23 rkukura: nice! 18:09:45 LouisF: The resource mapping driver will take care of creating the subnet for the EPG 18:10:14 The implicit policy driver will create the L2P for the EPG if one isn’t passed in explciitly 18:10:19 rkukura: these patches will be using the python-clients? 18:10:25 rkukura: and network also? 18:10:31 and the resource mapping driver will create the network for the L2P 18:10:50 The plan is for the resource mapping driver to use the python client for non-GP APIs 18:10:56 LouisF: L2P maps to the network 18:11:10 The implicit policy driver is currently calling the plugin directly 18:12:09 rkukura: when will use of python client be added? 18:12:10 It turns out the PoC code in these drivers needs significant work to be ready to review and merge, like deletion of resources, unit tests, etc. 18:12:24 s3wong: i believe you will need to use the python client for the security group mapping 18:12:35 SumitNaiksatam: yes - hence the question to rkukura :-) 18:12:39 LouisF: That will be added to the resource mapping driver before its posted for review, hopefully in the next couple days 18:12:58 s3wong: i realized that, hence reiterating :-) 18:12:59 rkukura: will look out for it 18:13:05 OK 18:13:40 LouisF: Do you see any problem with calling the GP plugin directly in the implicit policy driver? 18:14:02 rkukura: no 18:14:04 rkukura: perhaps having a very high level block diagram with the different pieces (implicit driver, mapping driver, etc) might help in review 18:14:14 +1 18:14:15 OK, great 18:14:18 rkukura: and posting on our GP wiki 18:14:41 rkukura: will you have time at all for this, or we can see if someone else can put it there 18:14:51 I’ll see if I can come up with something, but I’m on PTO, so I can’t get away with too much time on work 18:15:04 rkukura: why not :-) ? 18:15:12 Someone else doing the diagram would be great 18:15:43 working while snorkeling or ziplining would not go well 18:15:43 #action SumitNaiksatam to put block diagram for mapping driver (or delegate to someone else :-P) 18:16:18 while flying is fine 18:16:26 * SumitNaiksatam rkukura has planned an adventorous vacation! :-) 18:17:00 rkukura: any other questions for rkukura? 18:17:03 SumitNaiksatam: this is what we’ve been waiting for since the twins were born 16 years ago 18:17:15 rkukura: you absolutely deserve it! 18:17:20 enjoy 18:17:38 thanks 18:17:50 any other mapping questions 18:17:52 ? 18:18:26 mapping of policy rules to security groups? 18:18:33 s3wong: perhaps you want to give a quick update on the security groups mapping (to the extent that you have thought about it)? 18:18:41 LouisF: ah LouisF right on cue :-) 18:18:56 working on my timing... 18:19:11 SumitNaiksatam: still reading rkukura 's code to understand the structure of the current mapping driver 18:19:27 s3wong: sure 18:19:40 s3wong: whats the high level plan? 18:20:00 s3wong: for the benefit of everyone here 18:20:00 s3wong: I’ll probably be adding some tables in the driver, and maybe we could store the SG_id there 18:20:35 s3wong: Assuming we don’t want to expose the SG in the API like we do for the port, network, subnet, and router 18:21:26 rkukura: probably not 18:21:27 rkukura: yes, we certainly don't want to make SG visible in the API 18:22:09 s3wong, SumitNaiksatam: Is the rationale that we need complete control of the SG, and can’t let users muck with it? 18:22:27 rkukura: that has been the thinking until this point 18:22:31 rkukura: we should, right? 18:23:00 I agree we need complete control, since SG rule ordering is important, so we should not expose it in the API 18:23:20 rkukura: i think differnt backends can enforce the contract rules in different ways, so in that sense SG mapping is an implementation detail here 18:23:48 right, even if a backend exposes networks, subnets, and ports, it may not be using SGs for policy rendering 18:23:55 rkukura: yeah 18:24:08 seems we all agree to keep the SGs internal to the mapping driver, right? 18:24:19 rkukura: yes 18:24:28 rkukura: that said, to your point, i believe if the user really wants to muck around with the mapped SGs he would still be able to do it, right? 18:24:45 rkukura: i mean the mapped SGs would be visible to him 18:25:03 Unless we create them with a different tenant, the user can discover and update/delete them 18:25:15 rkukura: ok, so s3wong something to think about 18:25:22 will this SG that is "owned" by GBP appear in the SG list? 18:25:47 LouisF: we hadnt planned a separate “GBP” tenant until this point 18:26:01 rkukura: can a SG created by a different tenant be apply to traffic in the other tenant? 18:26:08 I think we should stick with using the client’s tenant for now, but keep the option open to change that later. But SGs may need to be the same tenant as the port - not sure 18:26:15 rkukura: +1 18:27:02 we can perhaps evolve with a new role, like what is being propose with the “adv services” role 18:27:26 #link https://review.openstack.org/101281 18:27:49 SumitNaiksatam: the "adv services" role gets admin previleges, right? 18:27:52 the above was FYI for the advsvs role 18:27:59 s3wong: yes 18:28:07 on a slightly different note 18:28:12 regarding the stacking of patches 18:28:27 may be i will change the topic 18:28:53 before that any other questions for s3wong on SG mapping (he just started looking at this, so be kind to him) 18:29:33 so kind :-) 18:29:36 s3wong: is there anything more that you need to sort out? 18:30:11 ok moving on 18:30:13 SumitNaiksatam: just generally understand what there currently, and how/when to invoke python-clients 18:30:21 s3wong: ok 18:30:31 SumitNaiksatam: so need more investigation before I can ask proper questions :-) 18:30:31 #topic Stacking of patches 18:30:36 s3wong: ok 18:31:10 so initially we had the plan to make progress in “bread” and “depth” fashion wih regards to stacking the patches 18:31:22 breath? 18:31:26 where depth goes from API to the driver/data path level 18:31:46 and breadth traverses the resources in the GP model 18:31:52 s3wong: ^^^ 18:32:03 :-) 18:32:12 to that end we have the depth series with EP, EPG, L2/3P 18:32:33 i started the breadth series with the classifier, action, rules 18:33:32 * SumitNaiksatam thinks needs rkukura’s help for 3 lettter acronymys for classifier, actions, rules 18:33:58 CARs 18:34:04 so the classifier, … API patch is currently based of the GP-plugin-1 patch 18:34:07 rkukura: :-) 18:34:29 but when you pull that GP-API-2 patch, you dont get any of the mapping stuff 18:34:41 or the anticipated driver stuff 18:34:53 and the SG mapping would need that 18:35:13 so the question is, should we have one linear series of patches? 18:35:35 i guess its unavoidable, but it will be one long series! 18:35:51 I think we’ll eventually need to make it linear, but short term can have forks 18:36:18 hopefully we can get the gp-*-1 series merged before too long 18:36:55 SumitNaiksatam: a side question on this. Is there any sync-up on the classifier between GBP and Traffic Steering when they are both used for support of service chaining? 18:37:05 for now, both gpm-*-1 and gp*-2 are based off gp-api-1, right 18:37:06 ? 18:37:26 rkukura: that was the hope that we would get it merged sooner 18:37:54 rkukura: yes, GP-API-2 is based off GP-Plugin-1 18:38:05 that’s what I meant 18:38:10 rkukura: yeah 18:38:17 Cathy_: thanks for bringing that up 18:38:29 so we could rebase gp-*-2 off of gpm-plugin-1 at any point 18:38:59 rkukura: yeah, actuall i would think GPM-Driver-*? 18:39:14 then later rebase them off gpm-rmd-1 18:39:59 rkukura: RMD? 18:40:01 gp-api-1, gp-db-1, gp-plugin-1, gpm-api-1, gpm-db-1, gpm-plugin-1, gpm-ipd-1, gpm-rmd-1, gp-api-2, …? 18:40:08 resource mapping driver 18:40:26 gpm-ipd-1 is implicit policy driver 18:40:35 rkukura: yeah, got that! :-) 18:40:54 SumitNaiksatam: sure. If you need any help on the part related to service chaining, please let me know. 18:40:57 rkukura: acronym czar! :-) 18:41:06 Cathy_: thats the next topic 18:41:17 #topic Services’ integration 18:42:03 i was hoping mandeep would be around to discuss the service chaining 18:42:12 is cgoncalves around? 18:42:14 I hope so 18:42:34 i dont see mandeep in this channel though 18:42:45 SumitNaiksatam: too late at night for folks in Europe 18:42:53 (not mandeep) 18:43:32 yeah, so both cgoncalves and mandeep are not around 18:44:11 Cathy_: the way i understand it, the service chaining bp was written to be independent of the implementation menchanism 18:44:41 Cathy_: which means that the TS is not strictly required for implementing the service chaining 18:45:02 Cathy_: also the intial focus of the service chaining bp is on the services which are exposed in neutron 18:45:37 SumitNaiksatam: Yes, I understand, but when it is used for service chaining, the API should not cause any conflict between the API in GBP or the other way around 18:45:42 Cathy_: in the GP reference implementation, we will point to a service or a service chain UUID in the redirect action 18:45:58 Cathy_: that is a good point 18:47:16 Cathy_: the port-chaining API in the TS bp is useful for chaining services which are realized in VMs and which Neutron is not aware of 18:47:38 i hope we still have everyone here after the split 18:47:53 here 18:47:54 SumitNaiksatam: could you clarify what is meant by point to a "service" in the redirect? 18:48:02 I was kicked out 18:48:05 y 18:48:07 I’m here 18:48:32 topic still intact, or maybe that's just my client 18:49:03 SumitNaiksatam: does that mean user can specify a sequence of service instance IDs after the "redirect"? 18:49:03 Cathy_: is you question whethe we will allow the port-chain to be used in the redirect action? 18:49:31 SumitNaiksatam: not really 18:49:47 Cathy_: we don't. Just ONE UUID for now 18:50:16 *whether 18:50:25 s3wong_: thanks. How about in the future? since SumitNaiksatam mentions "service" for redirect too? 18:51:05 Cathy_: for now we are thinking that if you want a chain, the chain would be created by service chaining APIs 18:51:31 since it is highly unlikely that the user of GBP APIs (app-owners) would want to chain his own service chains 18:52:18 s3wong banix Cathy_ LouisF: still there? 18:52:24 I think it is not chain his own service chain. It is redirect a flow to a service chain which consists of a sequence of service function instances, right? 18:52:24 SumitNaiksatam: hi 18:52:25 yes 18:52:28 yes 18:53:00 Cathy_: in that case, can the service functions be chained by the service chaining APIs? 18:53:20 s3wong_: not sure what you meant by that? 18:53:48 s3wong_: are you taking about the service chaining API in advanced service BP? 18:54:05 Cathy_: yes 18:54:12 here is my thought 18:54:57 are we all back? 18:55:01 The service chaining API can specify the sequence of service function instances which is identified by a unique chain-ID and this chain-ID can be used in GBP for the "redirect" 18:55:06 Cathy_: https://review.openstack.org/#/c/93524 18:55:32 Cathy_: yes 18:55:42 good, so now the issues is 18:55:57 s3wong banix rkukura songole Cathy_ LouisF: there? 18:56:05 we only need one place to specify the classifier 18:56:06 SumitNaiksatam: hello? 18:56:19 SumitNaiksatam: yes I am here. 18:56:20 yes 18:56:25 SumitNaiksatam: been here all along :) 18:56:33 SumitNaiksatam: here 18:56:43 my nic has changed though, from s3wong -> s3wong_ 18:56:43 oh i think i was on the other side of the split 18:57:00 i did not see any of the conversation until now 18:57:11 yes, back to s3wong instead s3wong_ :-) 18:57:18 s3wong_: but based on existing traffic steeing API and the GBP API, they are two places to specify the classiffier which can cause inconsistency. 18:57:43 Cathy_: so the classifier in GBP is used to apply policy 18:58:12 s3wong: yes, but the policy consists of the redirect and chain-ID 18:58:26 and classifier 18:58:41 Cathy_: the classifier in policy-rule does NOT need to be the same as TS' 18:58:50 and the chain-ID also carries over the classifier designed in the TS 18:58:52 Cathy_: lets not confuse the classifier in the TS with GBP 18:59:17 Cathy_: right now the thinking is very simple, the GBP has a redirect action 18:59:29 Cathy_: that redirect action has a value field 18:59:38 Cathy_: in fact, the TS' classifier is way more specific 18:59:38 Cathy_: that value field takes a UUID 18:59:48 Cathy_: it has a src-ip and dst-ip fields to them 19:00:01 Cathy_: that UUID can either be a Neutron service (FWaaS, LBaaS, or VPNaaS) 19:00:07 Cathy_: the chaining BP https://review.openstack.org/#/c/93524 does not have as classifier 19:00:17 Cathy_: or it can be a Service Chain UUID 19:00:33 s3wong: if the classifiers are not the same which one identifies the flow that will go through the service chain and what is the other classifier used for? Maybe I miss something here. 19:00:34 Cathy_: so what I can see possible, in the future - is that the mapping driver for 'redirect' COULD potentially use the TS python-clients to steer traffic to a service 19:00:46 Cathy_: where service chain UUID is as per the spec #link https://review.openstack.org/#/c/93524 19:00:52 Cathy_: even if a GBP implementation uses TS then it will set the classifier appropriately 19:01:19 LouisF: we are talking about TS API, not service chaining API 19:01:58 Cathy_: in the case of GBP mapping driver using TS, the TS parameters will be set up by GBP mapping driver to redirect traffic to a service (as specified by the UUID) 19:02:14 have to run unfortunately… see you all later 19:02:43 banix: thanks for the reminder 19:02:48 we are 2 mins over 19:02:57 Cathy_: IF the UUID specified happens to be a service chain - which also happens to use TS APIs (chains can use TS APIs too), then the chain's usage of the TS classifier is indpendent of how even the mapping driver is using the classifier 19:03:26 banix: have fun! 19:03:30 s3wong: I will talk with you off line. thanks 19:03:52 SumitNaiksatam: thanks for discussing this. 19:04:15 Cathy_: just pinged you on IM as well 19:04:23 Cathy_: we can discuss this further offline 19:04:28 SumitNaiksatam: sure 19:04:34 SumitNaiksatam: how to reach you? 19:04:51 Cathy_: check your IRC chat :-) 19:05:03 Cathy_: i just pinged you 19:05:13 is songole still here? 19:05:48 #topic CLI and client 19:06:09 wanted to get a quick update from songole since hemanthravi is away 19:06:27 talked to songole and he will be updating the CLI/Client patch at the earliest 19:06:35 to sync with GP-API-1 19:07:36 #topic open discussion 19:07:39 anytning else? 19:07:47 not sure who else is still in the meeting 19:08:17 ok lets wrap it up 19:08:24 #endmeeting