18:02:13 #startmeeting networking_policy 18:02:14 SumitNaiksatam: hello 18:02:15 Meeting started Thu Oct 23 18:02:13 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:16 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:02:18 The meeting name has been set to 'networking_policy' 18:02:45 #topic Specs in review 18:03:03 #link https://review.openstack.org/#/q/status:open+project:stackforge/group-based-policy-specs+branch:master,n,z 18:03:10 hi 18:03:24 the service chaining spec was reviewed and merged earlier in the week 18:03:44 i am behin on updating #link https://review.openstack.org/127913 18:04:05 happy to answer questions on that here, though 18:04:38 rkukura: are we still targeting #link https://review.openstack.org/128000 for juno-gbp-2? 18:05:13 SumitNaiksatam: Its possible - was just checking on where I was on that 18:05:33 When is juno-gbp-2? 18:05:57 rkukura: the original target is tomorrow :-) 18:06:16 when is juno-gbp-3? 18:06:26 rkukura: but i think we will have to make some exceptions, since we have been a little behind on the reviews 18:06:42 There is a chance I’ll have code in review Monday 18:06:59 So lets see where we are then. 18:07:09 rkukura: juno-gbp-2 was aligned so that the release would be ready before the Paris Summit 18:07:50 Does anyone plan to implement and extension driver for juno-gbp-2 if it is available? 18:07:57 s/and/an/ 18:08:01 I would say that it's a bit late to merge this before Paris? 18:08:01 rkukura: we need to stock of where we are with juno-gbp-2 and determine how we want to move forward with the branching (if we want to go directly to kilo-gbp or do a juno-gbp-n) 18:08:21 rkukura: that would be useful for me, but I've already posted a GBP APIC patch without the extension 18:08:37 rkukura: ivar-lazzaro: thats a good point, we might not have enough cycles to incorporate this into a driver 18:08:42 I thought our plan was to continue to iterate based on juno, and start supporting kilo in parallel at some point 18:08:46 rkukura: befor the paris summit that is 18:08:59 rkukura: yes, that is definitely up for discussion 18:09:07 rkukura: I would say that changing the implementation would be not doable unless the patch gets merged before this WE 18:09:56 rkukura SumitNaiksatam: yeah I definitively would love to see this for Juno, but I would not rush things for Paris at this point 18:10:02 ivar-lazzaro: lets see where we are on this tomorrow 18:10:15 nothing stopping us from approving this spec if there are no objections 18:10:32 SumitNaiksatam: sure, I'll fire the +A if we all agree 18:10:40 worst case we can just carry over the spec if we dont have the cycles to implement right away 18:10:50 ivar-lazzaro: no objections from me 18:10:51 comments are reasonable but I don’t think they require updates 18:11:18 i wanted to do a quick read, but would not want to hold up the merge 18:11:45 SumitNaiksatam, rkukura, ivar-lazzaro: with RMD-SG merged this morning, we should be at where we wanted to be at for Juno (code-wise and functionality wise, at least on the server side), right? 18:11:50 the alternatives listed are only partial, but I think they are stil worth mentioning 18:11:52 SumitNaiksatam: go ahead, I think the implementation can be sent in review even if the spec is not fully approved 18:12:21 s3wong: we will get to the implementation shortly 18:12:25 s3wong: I would say that we miss hierarchical contracts at least 18:12:40 hemanthravi: you have #link https://review.openstack.org/#/c/129490/ 18:12:43 ivar-lazzaro: hmm... true 18:12:58 ivar-lazzaro: s3wong: if you dont mind, lets first discuss the specs 18:13:03 Also I was wondering, where are the other drivers' implementation? I think OneConvergence had one? 18:13:28 ivar-lazzaro: good point, hemanthravi ^^^ 18:13:51 hemanthravi: are you planning to post the spec that was earlier posted and approved in neutron? 18:13:56 SumitNaiksatam, will post our driver in the next 1-2 days 18:14:05 for the driver, yes 18:14:11 hemanthravi: would need the spec as well 18:14:19 will do 18:14:25 hemanthravi: thanks 18:14:37 hemanthravi: regarding the HEAT-related spec 18:14:51 yes, need a review on that one 18:15:18 so for the benefit of everyone, what are we proposing, and what are we reviewing here? 18:15:49 this is the same as what was posted in neutron earlier, heat support for all GBP resources 18:16:01 ivar-lazzaro: did you post a APIC driver spec, or did i completely miss it? 18:16:25 SumitNaiksatam: no I didn't, and honestly I don't find it atm :) 18:16:38 SumitNaiksatam: not sure if Neutron dumped those specs 18:16:43 ivar-lazzaro: oh 18:17:08 ivar-lazzaro: okay we will sync up on that offline 18:17:14 SumitNaiksatam: yep 18:17:33 SumitNaiksatam: I got regXbo's consent to take over the ODL piece, but it probably won't make gbp-juno 18:17:56 s3wong: thats nice, and no worries 18:18:10 s3wong: as long as we have an owner 18:18:20 s3wong: can you post the spec? 18:18:38 SumitNaiksatam: yes, will do that before tomorrow (ODL status meeting) 18:18:48 s3wong: thanks 18:19:11 hemanthravi: so the changes in your spec https://review.openstack.org/#/c/129490 are targeted at Heat, right? 18:19:29 SumitNaiksatam, yes need a review :) 18:20:05 i am just wondering how we can clarify that this is a Heat related change, not clear right now 18:21:04 perhaps we should create launchpad projects in the respective projects (so https://launchpad.net/group-based-policy-automation in this case) 18:21:37 that way you can link your gerrit spec to the bp in that LP project 18:22:21 so essentially i am saying, move: https://blueprints.launchpad.net/group-based-policy/+spec/group-based-policy-automation to https://blueprints.launchpad.net/group-based-policy-automation/+spec/group-based-policy-automation 18:22:58 hemanthravi: make sense? 18:23:29 SumitNaiksatam, can do that if the current loc doesn't work 18:24:28 hemanthravi: yeah, i think we will need to do that 18:24:40 hemanthravi: since this is not a server side spec 18:25:07 hemanthravi: sorry for the process overhead 18:25:39 ok, will catch up with later today and get this done 18:25:49 hemanthravi: thanks much! 18:26:02 ivar-lazzaro: is #link https://review.openstack.org/#/c/127380/ on hold? 18:26:39 SumitNaiksatam: just waiting for more reviews, this item is also after-Paris though 18:26:47 ivar-lazzaro: okay got it 18:26:50 LouisF: hi 18:26:51 ivar-lazzaro, SumitNaiksatam: I can review that too 18:26:59 SumitNaiksatam: hi 18:27:01 s3wong: thanks 18:27:05 LouisF: which spec patch should we be reviewing? 18:27:26 SumitNaiksatam: I will update the specs 18:27:33 SumitNaiksatam: FYI: https://review.openstack.org/#/c/130615/ 18:28:04 ivar-lazzaro: ah that was fast, at the speed of ACI! :-) 18:28:29 SumitNaiksatam: ahah :) 18:28:58 LouisF: so all the separate patches are basically one spec, right? 18:29:12 SumitNaiksatam: yes 18:29:56 ok moving on to the implementation patches 18:30:14 #link https://review.openstack.org/#/q/status:open+project:stackforge/group-based-policy+branch:master,n,z 18:30:45 the great news is that GPM-RMD-SG #link https://review.openstack.org/#/c/124941 was merged earlier today 18:30:56 yeey 18:31:11 thanks rkukura for the reviews, and ivar-lazzaro for the quick responses, great work! 18:31:48 It certainly had undergone quite a few changes since I posted it on Neutron; thanks for ivar-lazzaro for picking up this mess :-) 18:32:18 the remaining GBP model patches are smaller 18:32:19 s3wong: if anything, I made it even messier :D 18:32:34 its a start - plenty more work to do 18:32:38 and there are a whole series of service chaining patches 18:33:07 hemanthravi: there are two sets of patches 18:33:54 SumitNaiksatam, what do you mean 18:36:14 hemanthravi: so there are patches posted by Subra and there are patches posted by Magesh 18:36:46 sumit magesh rebased them to make it a liner dependency 18:36:49 hemanthravi: Subra’s initial patch #link https://review.openstack.org/127038 is marked WIP 18:36:51 those are the right patches 18:37:16 will check with subra and abandon the earlier ones 18:37:17 hemanthravi: ah ok, can you request Subra to abandon his patches? 18:37:34 hemanthravi: great, will reduce confusion 18:37:50 SumitNaiksatam, will do 18:38:22 ivar-lazzaro: your patch on hierarchical contracts has no core reviewers :-) 18:38:26 #link https://review.openstack.org/#/c/127364/ 18:38:38 okay i just added 18:38:50 SumitNaiksatam: ops :) 18:39:00 SumitNaiksatam, the patches in https://docs.google.com/a/oneconvergence.com/spreadsheets/d/1VAcYODD5fA_t2yleb95pTlIxD-btnUllZTN-uhNrsh4/edit?pli=1#gid=0 18:39:10 hemanthravi: so i should review Magesh's patches? 18:39:28 LouisF, yes these are posted in the google doc 18:39:29 too 18:39:38 hemanthravi: got it, i should have checked 18:39:39 LouisF, thanks 18:40:15 SumitNaiksatam, will abandon the duplicate patches to remove the confusion 18:40:16 hemanthravi: on the service chain patches what is the delta between what is posted here and what was earlier proposed in Neutron? 18:41:15 there are some changes related to the support for params requested by the spec 18:41:41 hemanthravi: okay, that ties into my changes as well 18:41:57 #link https://review.openstack.org/129545 18:41:57 and the api change for the servicechaininstance to use epg(s) 18:42:05 hemanthravi: ok 18:42:05 or ptg(s) once renamed 18:42:45 so #link https://review.openstack.org/129545 implements #link https://review.openstack.org/#/c/127913 18:43:14 i havent updated that spec patch though 18:43:30 hemanthravi: thanks for your clarifying comments in response to rkukura’s questions 18:44:12 basically, we are introducing a new “network service policy” resource (similar to L2P, L3P; you can call it NSP) 18:44:41 SumitNaiksatam: ;) 18:45:03 rkukura: i knew i had a chance with winning you over with that! ;-) 18:45:23 SumitNaiksatam: sorry that I haven't read the spec --- how does NSP work? 18:45:25 this is used to capture policy information that is relevant to the service chain and in the context of an EPG 18:46:06 essentially, for every service chain that needs to be realized (or for the service instances that need to be realized in that service chain) certain resources need to be allocated 18:46:27 by resources you can think of, say, an IP address for a VIP 18:47:11 NSP becomes the place to define the policy for allocating these resources (just like we did in L2P and L3P) 18:47:43 hemanthravi: did i capture that accurately at least at a high level? 18:48:05 SumitNaiksatam, yes 18:48:12 s3wong: hopefully answered your question 18:48:46 SumitNaiksatam: still need to look at spec and code... would love to see the level of abstraction to specify service specific resources 18:48:57 s3wong, the service-chain-spec request for a list of params and NSP defines how these resources will be allocated bu GBP 18:49:01 SumitNaiksatam: but I understand the intent now 18:49:09 s3wong: ok good 18:49:34 SumitNaiksatam: so you would use the NSP object to instantiate services instead of the service insertion/chaining API? 18:49:35 hemanthravi: interesting... will read more 18:49:44 ivar-lazzaro: no 18:49:55 ivar-lazzaro: it sounds like GBP will realize the service chain 18:50:00 s3wong, interesting in a good way :) 18:50:06 ivar-lazzaro: the service chain provider/driver would use the NSP when instantiating the service chain 18:50:30 SumitNaiksatam: what patch covers nsp? 18:50:49 ivar-lazzaro: so the service chain provider knows that it needs a VIP (for example) since the chain has a LB 18:51:22 hemanthravi: keeping service chaining at a high-level (it sounds like it is basically at Heat type level) would also make markmcclain happy :-) 18:51:34 SumitNaiksatam: Why does the chain provided need to understand the service underneath? 18:51:35 ivar-lazzaro: however the resource allocation (in terms of IP address for that VIP) should be done by GBP (per our policy-based design philosophy) 18:51:44 SumitNaiksatam: I need to give a deeper look to those specs :) 18:52:08 ivar-lazzaro: chain provider always has some understanding of the service underneath 18:52:26 s3wong, heat is used for static definitions of the services but some of the dynamic parameters are dependent on the context where the chain is realized 18:52:43 s3wong, these are provided via the NSP 18:52:44 ivar-lazzaro: in this case the understanding is to the extent, that the provider knows that the LB service would need a VIP (perhpas it does not specifically understand what a VIP is) 18:52:52 hemanthravi: cool 18:53:08 LouisF: #link https://review.openstack.org/#/c/127913 and #link https://review.openstack.org/129545 18:53:18 SumitNaiksatam: thx 18:53:55 since we have only a few minutes left, lets shift gears 18:54:00 SumitNaiksatam: what's the difference between a "VIP" and a simple neutron port? (that is what current LBaaS implementation asks for the VIP) 18:54:16 hemanthravi: can non-openstack services be described by heat? 18:54:23 SumitNaiksatam: In this context, you can get the allocation by simply having a PolicyTarget 18:54:55 LouisF: I would imagine non-Neutron aware services would NOT be included in this iteration 18:55:18 s3wong: agree but thinking about 18:55:27 LouisF, heat can be extended with plugins that can use a ReST API to talk to these services.. I think this should work 18:55:28 ivar-lazzaro: GBP does not understand what a VIP is, that is not what we are trying to do here 18:55:47 (in any case ... if we are moving to Open Discussion... I have something to ask the team) 18:55:52 ok we need to move on to cover the remaining topic 18:56:00 #topic GBP Design Summit Session in Paris 18:56:12 SumitNaiksatam: that would do also :-) 18:56:14 #link http://kilodesignsummit.sched.org/event/98dc4255384e340682137c8a7ee7e60d 18:56:41 so we have an etherpad: #link https://etherpad.openstack.org/p/kilo-gbp-design-summit-topics 18:56:46 Before I forget.. sarob asked on the ML whether our team (GBP team) would like to collaborate with Congress on some joint workshop / cross-project stuff 18:57:04 what does the team think? 18:57:27 s3wong: i think the question was in the context of moving the Congress session 18:57:34 they took the initiative to put their design summit session to the same day as ours 18:58:14 SumitNaiksatam: yes, but at the end of the email, he talked about "Maybe we can get some space in one of the pods or cross-project workshops on Tuesday between the GBP and the potential Congress session to make it even more better" 18:58:56 s3wong: yes that would be cool 18:59:02 we have one minute 18:59:13 so please put your thoughts on the etherpad 18:59:31 in terms of what we want to discuss in the design summit session 18:59:44 a lot of what we have discussed here will carry forward there 18:59:58 we have 45 mins, so we will have to budget accordingly 19:00:04 any other parting thoughs? 19:00:04 SumitNaiksatam: we are still going to have a meeting before K-Summit, right? 19:00:11 *thoughts 19:00:14 i.e., next Thursday? 19:00:21 s3wong: good question 19:00:33 s3wong: what does the team think? 19:00:38 i am up for it 19:00:51 may be we can keep it short - 30 mins as a quick status update 19:00:59 SumitNaiksatam, hemanthravi: we also need to coordinate our presentation before then 19:01:16 (before Paris) 19:01:17 s3wong: i have updated the presentation, shared with you 19:01:33 it is on Monday, afterall :-) 19:01:50 SumitNaiksatam: great. Will take a look 19:02:01 s3wong: reviews and finishing the implementation is the first priority ;-) 19:02:15 SumitNaiksatam: +1 :-) 19:02:29 okay thanks everyone! 19:02:32 bye 19:02:35 #endmeeting