17:02:46 #startmeeting service_chaining 17:02:47 Meeting started Thu Jun 25 17:02:46 2015 UTC and is due to finish in 60 minutes. The chair is cathy_. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:02:48 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:02:50 The meeting name has been set to 'service_chaining' 17:03:01 hi everyone 17:03:05 hello 17:03:16 o/ 17:03:21 hi cathy 17:03:21 Hi :-) 17:03:37 vikram_: welcome back 17:03:42 hi 17:03:45 :) 17:03:50 OK, let's go to topic #1 17:03:50 :) 17:04:19 #topic Neutron port chain API spec discussion 17:05:33 I see comments some of us have posted and also replies to comments. Any questions on the replies? 17:05:59 so it seems like Louis just updated the spec 17:06:04 Hi Cathy .. python client cli changes completed .. and submitted for review .. 17:06:11 s3wong: I replied to your comments. Are you OK with them? 17:06:14 o/ 17:06:35 mohankumar__: great, let's go to that in our next topic 17:07:04 cathy_: yes -- that was just a point, but no need to address from the get-go (regarding multiple port-chains on the same port that may have overlapping classifier matches) 17:07:37 s3wong: OK, good. 17:07:49 mohankumar__: are you talking about the python neutronclient changes for the api 17:08:13 any other questions/comments we would like to discuss in this IRC meeting? 17:08:17 Yes .. 17:08:26 Is this in the spec doc 17:08:29 Swami: yes. it is the python neutron client changes 17:09:39 Swami yes .. some addition I did for list and show clis 17:09:49 mohankumar__: thanks 17:09:53 i would like everyone to provide their views on https://etherpad.openstack.org/p/flow-classifier 17:10:32 yes, please go to the etherpad to provide your input and we can update the neutron port chain spec to include them 17:10:46 vikram_: thanks for setting that up 17:11:06 cathy: thanks 17:12:10 i feel once the BP is approved we can start the work about flow classifier otherwise rework will be more 17:12:42 cathy_, vikram_: is the generic classifier a different project altogether from SFC? 17:12:45 in our last meeting, we agree on a time to finalize the port chain API which is yesterday. So I would suggest that everyone go to the updated spec and review it again, post comments if you have more or give it +1 if you feel we can start implementing the API 17:12:56 s3wong: no 17:13:12 vikram_: but we need to get a consensus on the flow classifier before we start our work or that can be done in parallel. 17:13:14 the generic classifier will be included in our SFC spec 17:14:03 swami: i feel we can start the work in parallel.. 17:14:04 s3wong: good question. flow classifier is a key part of the SFC delivery and we can not say we deliver SFC without the classifier. 17:14:15 cathy_: and it will be part of the work item for Liberty? 17:14:31 s3wong: Yes, we are targeting that that release. 17:14:47 BTW, i want to start with the existing proposal so that i will be ready with the changes when others needs it 17:14:52 s3wong: the project has been officially accepted by Neutron 17:15:01 vikram_: ok, but that might cause more changes to the code who is implimenting the classifier. But if you thing that other parts of the sfc can proceed and classifier can catch then it makes sense. 17:15:32 Now it all depends when we can get the code completed and integration testing completed. 17:16:11 cathy_: so we need to limit the scope for the generic classifier, and view SFC as the primary use case for now 17:16:14 s3wong: I will work with Kyle Mestery how to release this feature 17:16:27 s3wong: yes, agree with you 17:16:42 Swami: IMHO, the existing proposal about flow-classifier is generic and I don't feel classifier will need lot of changes 17:17:08 vikram_: is that an assumption. 17:17:27 the functionality of the generic classifier proposed in the SFC spec will be the one we deliver and it cna be easily extended since we will implement it as a modular component that cna be used by other use cases 17:17:55 Swami: I have read both the proposals and to me flow-classifier and classifier are almost same 17:18:29 Swami: yes, agree with vikram. I have read both too, they are the same 17:18:49 vikram_: if they are the same we need to consolidate and make it a single BP 17:19:00 Swami: Exactly 17:19:01 cathy_: so that there is no issue later. 17:19:04 +1 17:19:24 Swami: Maybe you would like to read them too. If you see any major difference, let's discuss in our next IRC meeting. OK with you? 17:19:29 vikram_: that is what I mentioned by getting consensus with different BP owners. 17:19:38 i will be working with Yuji and merge it one 17:19:39 cathy_: thanks will do. 17:19:42 Swami: should be no issue. 17:19:53 Swami:+1 17:20:16 vikram_: Thanks for working with Yuji!! 17:20:59 I know Yuji can not join this IRC meeting and Thanks Vikram for working with him in another time slot 17:21:01 Cathy: I have a question about the code submission 17:21:15 what topic we need to mention in the patch 17:21:44 and how the patches will be reviewed 17:22:03 sorry all, if I am off topic 17:22:04 vikram_:not sure what you mean? Isn't it service chaining 17:22:05 vikram_: topic can be "bp-networking-sfc" 17:22:14 ok 17:22:23 So if all the patches go in with the same topic, it would be easy for the reviewers to sort it. 17:22:56 +1 17:23:05 Swami: I see. Yes. makes sense 17:23:25 shall we use "networking-sfc"? 17:24:13 yes "bp" states that you are implementing the blueprint for "networking-sfc". 17:24:22 but if you don't want "bp" I am ok with that. 17:24:30 end of the day it is just a "tag". 17:24:51 Swami: Actually I am OK with either one. How about others? which one you prefer 17:25:01 +1 for "networking-sfc" 17:25:39 networking-sfc 17:25:45 +1 for 'networking-sfc' 17:25:53 cathy_, Swami: doesn't matter, just settle on one so we are consistent. networking-sfc has less typing :-) 17:26:17 Ok, let's use "networking-sfc" 17:26:24 How we want to implement flow-classifier.. I feel it will be better as core-extension 17:27:02 Any suggestion's 17:27:15 For flow classifier, I will work with Jay Pipe to see how we position the implementation. 17:27:54 Since he gives comment on security group. But we replied to his comments on the limitation of security group 17:27:55 vikram_: I think we will finalize via your etherpad... given that Yuji isn't here, it may be good to finalize on the etherpad 17:27:58 We need to conclude for coding 17:28:23 S3wong: Make sense 17:28:43 Jay had suggested re-use of SGs instead of a flow-filter/classifier 17:29:24 but I think a separate flow-filter/classifer is a better approach 17:30:01 cathy_, LouisF: SG rules are created to attached directly to SG, though it is a resource by itself, it isn't being used outside of SG 17:30:23 vikram_: please bring back the discussion result with Yuji in our next IRC meeting. Basically we need to reach consensus on whether to extend security group or create a more indepenedent new flow classifier 17:30:37 s3wong: we agree with you 17:30:51 s3wong: that is our reply to Jay Pipe too 17:31:21 Cathy: Sure 17:31:32 cathy_, LouisF: in fact, a SG rule can't even be shared between two SGs, so how do we refactor that out would be quite a bit of work 17:31:45 vikram_: what's your opinion on using SG or a new independent flow classifier? 17:32:17 s3wong: agree, a separate FF/classifer would be better 17:32:27 I am not familiar with Security Group in detail.. Need to dig more 17:32:58 s3wong: exactly. I think most of us agree that we should use a separate indepenent flow classifier. 17:33:58 Swami: are you OK with implementing a separate flow classifier instead of using the SG? 17:34:13 cathy_:+1 17:34:30 Swami: thanks 17:34:44 cathy_, LouisF, vikram_: in fact, SG is so widely used, if we were to say add DSCP match on SG rules, it will have major regression effect 17:34:51 it is just so unideal 17:35:07 s3wong: that's a good point 17:35:14 s3wong: yes, 100% agree with you. 17:36:13 then flow classifier makes more sense as it can be extended easily 17:36:31 Could you go to the spec and give it a one more review and give +1 if you think we can start implementing the API? We really need to finalize this. 17:37:03 sure 17:37:33 Let's move to next topic 17:37:51 #topic SFC code implementation 17:37:52 cathy_: sure 17:37:53 s3wong: agree - changing SG rules will have regression issues 17:38:55 mohankumar__: would you like to update on the Neutron client code status for SFC? 17:39:36 Yes .. Will do 17:39:39 https://review.openstack.org/#/c/194648/ 17:41:05 Patches submitted .. pls review 17:41:12 vikram_: mohankumar__: I would say that we should have the server side code first and the client side code comes in at the end. 17:41:35 mohankumar__: OK, we will review it today. BTW, have you done some unit test? 17:41:56 mohankumar__: will be testing with your code today 17:42:12 Swami: yeah, that's normally the order... 17:42:29 UT .. Will do once rework done 17:42:35 :wq! 17:42:51 Swami: We will start implementing the server side API now. And do some testing on the client side code. 17:42:53 Louis F thanks 17:43:06 cathy_: thanks 17:45:15 mohankumar__: we will test your code. In the mean time you can start working on the Horizon part. 17:45:30 mohankumar__: vikram_ OK with you? 17:45:45 okay 17:45:45 Yeah ok 17:46:07 mohankumar__: great. Thanks. 17:47:04 cathy: what's the plan on BP approval 17:47:20 Is Nicolas in this meeting? We can discuss about application ID he suggested if he is in this meeting 17:47:39 seems he is not in the meeting. 17:48:18 Any thing else anyone would like to discuss? Otherwise I will summarize the action items 17:48:34 cathy: what's the plan on BP approval 17:53:07 vikram_: good question. After people giving -1 change to +1, I can start approve it and then I will ask Kyle and armax to approve too. SFC project has a separate core team to approve the BP. 17:53:47 Now let me summary the agreement and action items for this IRC meeting 17:54:00 cathy_: right, SFC specs go into SFC repo, so it should be +2/+A by SFC cores 17:54:23 #agree we reached consensus on the flow classifier in this meeting: we will implement a separate independent flow classifier instead of using/extending SG. Vikram will bring back consensus with Yuji in next IRC meeting 17:56:04 #action Everyone review the Client API codes for SFC and test the API with Server side API 17:57:38 #agree topic for the code patches: networking-sfc 17:58:00 s3wong: yes. 17:58:35 Ok, thanks everyone for joining the meeting, Let's discuss more in next IRC meeting. Bye now 17:58:42 bye 17:58:42 bye 17:58:44 bye 17:58:47 bye 17:58:49 Bye 17:58:49 bye 17:59:05 #endmeeting