17:02:07 #startmeeting service_chaining 17:02:08 Meeting started Thu Jul 23 17:02:07 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:09 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:02:12 The meeting name has been set to 'service_chaining' 17:02:19 hello 17:02:21 hi everyone 17:02:22 hi 17:02:28 hi 17:02:55 hi 17:02:56 hi 17:03:04 good let's start 17:03:51 we posted a new patch for the API spec to address Sean's comment on adding the API URL table. Have you got a chance to review it? 17:03:56 #link https://review.openstack.org/#/c/204695 17:04:26 this adds detail on the url and resource endpoints 17:04:49 sc68cal: are you there? 17:05:00 LouisF: may want to just add sc68cal as reviewer, so it would be on his review queue 17:05:16 s3wong: good point. will do 17:05:29 looking now 17:06:07 I missed that one, but looking at it now I like it. I'll spend a little more time later before putting in a review. 17:06:20 anything you folks would like to discuss in today's meeting? We have a wiki page posted in last IRC meeting. you can go there to add items you would like to discuss in the coming IRC meeting 17:06:27 cathy_: will review it 17:06:40 I have an item 17:06:45 pcarver: thanks. 17:06:50 vikram: thanks 17:07:10 Can we get some cross-collaboration on this spec? https://review.openstack.org/186663 17:07:15 sc68cal: that was fast :-) 17:07:32 sc68cal: I am looking at that spec. 17:07:53 s3wong: well my objection was just that the info was in a wiki, not in the actual API spec - it wasn't an objection to the API overall 17:08:11 sc68cal: sure 17:08:12 https://review.openstack.org/186663 - I would like to see just one API for forwarding and forwarding-like things 17:08:36 interesting. That does seem like it overlaps 17:08:47 yes they may be slightly different - re the whole chain concept but we don't benefit from having multiple ways to express similar concepts 17:08:49 sc68cal: yes, we have been collaborating with that spec. Vikram had worked with Yuji of that spec on reaching consensus on the Classifier API we put in the service chain spec. 17:09:04 sc68cal: we do also --- the tradeoff however is that networking-sfc would have a dependency on this to land 17:09:20 cathy_: this is another spec.. 17:09:22 sc68cal: if you look at previous meeting logs, we have discussion on that and community consensus on that 17:09:43 sc68cal: i feel this spec is unrelated to service function chaining 17:10:01 spec just try to provide a way in which a transparent packet can be directed to a particular dest-port. Here the idea of chain is not involved as the packet will only be routed from a particular source to the required destination. 17:10:28 vikram: agree - it addresses filtering but not service chaining 17:10:34 sc68cal: Sorry this seems another spec, not the one Yuji posted on flow classifier. Sorry for the confusion 17:10:56 sc68cal: what is your felling? 17:11:00 *felling 17:11:08 the common classifier spec is https://review.openstack.org/#/c/190463/ 17:11:15 i am really bad at spellings :-) 17:11:25 sc68cal: though mestery and armax are on the reviewers list, I don't see a whole lot of core awareness on this effort --- so definitely a bit concerning if we make this a dependency 17:11:55 vikram: it's not the same but it has a lot in common. If we're going to have both there will need to be extremely clear documentation to guide operators and tenants on when to use each. 17:12:16 Especially if the two can interact in unpredictable ways 17:12:19 pcarver: i agree.. 17:12:23 I just feel like there are some things that are in common, the idea of redirecting traffic - the mechanics may be different but I don't like this idea of "oh it's just a little bit different, therefore a whole new separate API is justified" 17:12:52 sc68cal: hmmmm 17:13:20 cathy_: I understand the desire to not have too many dependencies, but it may make sense to have a have one be a degenerate case of the other 17:13:36 sc68cal: we can hold it unless we have a definite usecase which could not be resolved using service function chaining 17:13:36 sc68cal: +1 17:13:42 as opposed to two unrelated things that appear similar to the user 17:14:04 sc68cal: the sfc is more general than the forwarding spec 17:14:30 its functionality can be covered by the sfc spec 17:14:36 sc68cal, pcarver: I agree, service function chaining can achieve the use case defined in forwarding spec 17:15:06 LouisF, vikram: I haven't reviewed 186663 before looking at it just now, but is there a reason why it couldn't be implemented as a trivially simple service chain? 17:15:09 How about holding it unless we have a definite usecase which could not be resolved using service function chaining 17:15:28 pcarver: in theory I 100% agree with not duplicate effort. But we also understand that merging things in Neutron is of a different pace than merging things in networking-sfc (the point of separate repo is to iterate faster) 17:15:31 vikram:agree with you. Would you like to talk with Yuji on that ? 17:15:32 pcarver: I believe it can 17:15:36 pcarver: yes I think that can be done 17:16:03 yeah I mean I could be stupid but the forwarding API is basically just a chain of 1 17:16:11 cathy_: We can put our concerns over the etherpad link shared for this spec 17:16:14 and BTW - fwaas is going to be a chain of 1 17:16:26 https://etherpad.openstack.org/p/forwarding-rule 17:16:27 if we're inserting a firewall between an instance and the rest of the network 17:16:52 I had hoped to consume SFC, to look into making fwaas more flexible 17:17:00 sc68cal:+++100 17:17:41 sc68cal: +1, security functions are a primary example of the reason for SFC, although not all chained functions are firewallish 17:17:55 +1 17:18:27 So we all agree that the service chain API can cover the functionality needed in https://review.openstack.org/#/c/186663/ 17:18:41 +1 17:18:58 I'm also hearing requirements from the NFV side wanting to replicate hub and spoke topologies. I'm viewing that also as a subset of SFC 17:19:41 pcarver: agreed 17:19:42 #agreed the service chain API can cover the functionality needed in https://review.openstack.org/#/c/186663/ 17:21:16 So how should we make sure there is no duplicate API? Maybe Vikram can communicate this with Yuji? Suggestion? 17:22:13 I'd say maybe an e-mail to the ML, with the results of this meeting, and say that we want to try and converge where there is commonality 17:22:19 cathy_: sure.. i have posted a comment on the spec.. will try to catch him tomorrow over IRC as wekk 17:22:45 sc68cal: agree. 17:23:24 cathy_: I haven't gone through the review in detail, but I'm thinking that it might not be wrong to have a sort of a wrapper for specific subcases. What I wouldn't want to see is uncoordinated duplication of effort. 17:23:55 #action Cathy send an email to ML summarizing the consensus that the service chain API can cover the functionality needed in https://review.openstack.org/#/c/186663/ 17:24:12 It may be that 186663 shouldn't just be abandoned, but revised to be based on SFC 17:24:33 #action: Vikram try to catch him tomorrow over IRC and pass our consensus to him, get his input. 17:25:33 pcarver: OK with me . You may want to post that suggestion to that spec 17:25:45 pcarver: but you are still advocating that the forwarding-rules/classifier effort be done on Neutron repo? 17:26:21 s3wong: Not advocating anything specific yet. I haven't read the 186663 spec yet. 17:26:34 cathy_: I will review that spec and post my thoughts 17:27:21 pcarver: good. thanks. I think the key is not to have duplicate APIs to confuse the community. 17:27:50 sc68cal: Thanks for starting this discussion topic! 17:28:03 np 17:28:07 any other topic you folks would like to discuss? 17:29:01 I've been looking at Google search results related to Neutron service chaining. I'm thinking we need to do some cleanup. 17:29:16 The top results tend to show up obsolete information 17:29:41 Louis' abandonded spec for example, and a wiki with old info and an outdated document 17:29:59 e.g. https://wiki.openstack.org/wiki/Neutron/ServiceInsertionAndChaining 17:30:08 pcarver: yeah, the top result (https://wiki.openstack.org/wiki/Neutron/ServiceInsertionAndChaining) has been obsolete since Juno... 17:30:27 I'm going to start doing a little editing, but it would be good if other people took a look too 17:30:37 pcarver: not sure how to fix that? Any clue? 17:30:42 that work was started some ago and was abandoned 17:31:03 The wiki is easy. Launchpad also. Gerrit I'm not sure 17:31:16 Anybody good with Gerrit URLs? 17:32:06 pcarver: so you are going to fix the search result of wiki and launchpad? 17:32:36 pcarver: I will talk with you offline about how to fix that. I would like to learn:-) 17:32:43 This blueprint https://blueprints.launchpad.net/neutron/+spec/neutron-api-extension-for-service-chaining lists this URL: https://review.openstack.org/#/q/topic:bp/neutron-api-extension-for-service-chaining,n,z 17:32:51 cathy_: I think pcarver is going to remove the wiki and launchpad pages :-) 17:33:08 Google search / cache, we can't do much about... 17:33:23 anybody know the correct URL to replace that so that it shows the new spec rather than the abandoned one? 17:33:48 pcarver: I can fix that 17:34:27 #action cathy modify the BP to reference the new spec 17:34:45 s3wong: :-) 17:35:01 how is the dependency issue of the Neutron SC client on the base code going? Vikram: any update? 17:35:13 resolved:-) 17:35:21 vikram: Cool ! 17:35:22 thanks to amotoki 17:35:25 yes , We got solution for base dependecency issue( by adding requirements in requirements.txt) 17:35:41 pcarver: https://review.openstack.org/#/c/192933/ 17:35:43 we need to add something in test-requirement.txt 17:35:45 Mohankumar__: great. that simple :-) 17:36:11 cathy_ yes :) 17:36:25 s3wong: That URL is in there, but it's a different view than the other one 17:37:01 s3wong: That URL is listed as "Addressed by" whereas the incorrect URL is listed as "Gerrit topic" 17:37:26 Oh, I think I just figured it out 17:37:43 Our topic is someone confusingly called "initial-manifesto" 17:38:08 the incorrect one is called neutron-api-extension-for-service-chaining 17:38:10 pcarver: ? 17:38:23 pcarver: yeah, I noticed that a while back :-) was wondering what the heck does that mean... 17:38:51 what is the official "Topic"? 17:39:04 pcarver: could you clarify what you are talking about? 17:39:35 It looks like blueprints typically list a Gerrit search URL at the top followed by a series of "Addressed by" links to specific URLs 17:40:07 cathy_: take a look at https://blueprints.launchpad.net/neutron/+spec/neutron-api-extension-for-service-chaining and scroll down to the Whiteboard section 17:40:40 cathy_: Note that there are two URLs, one "Gerrit topic" and one "Addressed by" 17:41:08 The "Gerrit topic" is actually a dynamic query that hits on Louis' abandoned changed 17:41:23 yeah, so fixing the Gerrit topic link should suffice 17:41:26 pcarver: will fix 17:41:27 So we need to change the Gerrit topic to the new one, right? We cna manually change that I assume? 17:41:29 The Addressed by is a correct link to our merged spec 17:42:06 cathy_: I think the correct link to replace the Gerrit topic is: https://review.openstack.org/#/q/status:merged+project:openstack/networking-sfc+branch:master+topic:initial-manifesto,n,z 17:42:52 it's just a little weird because the actual topic name isn't as natural 17:43:30 pcarver: So we might need to make the topic name natural 17:43:45 otherwise it is confusing. 17:43:52 cathy_: I'm not sure it's worth changing 17:43:54 what's wrong with initial-manifesto? :-) 17:44:12 I was just commenting that it's a bit odd 17:45:12 s3wong: what is meant by initial-manifesto? I did not pay attention to this before 17:45:50 cathy_: look at the "Topic" field at the gerrit for the API spec (https://review.openstack.org/#/c/192933/) 17:46:07 LouisF: Did you just update the blueprint? I don't think that's quite right. I think we want it to list all the reviews including the one that just merged. 17:46:09 "initial-manifesto" 17:47:26 pcarver: ok 17:47:58 pcarver: I agree we should list both specs which have many comments since the new one is a rebase of the old one. 17:48:31 #action Louis update the BP to refer to both specs which have all the reviews 17:48:41 And multiple links to the correct info should help improve the ranking in search engine results. I'll update the wiki to point to the blueprint and the API spec 17:49:00 pcarver: Thanks! 17:49:29 #action pcarver updates the wiki to point to the blueprint and the API spec 17:50:33 Just an update on the API implementation. We are almost done and will post it for review mid next week. 17:51:22 Any other issues for discussion? 17:51:26 cathy_: roughly where in the code are you working on the implementation? 17:51:52 pcarver: not sure what you mean? 17:52:09 cathy_: may be worthwhile to put unfinished patches on gerrit for early review (with workflow set to -1) 17:52:29 I mean where is the flow table manipulation happening? 17:52:46 pcarver: We will add SFC API handling and DB codes in the Neutron Server 17:53:09 pcarver: flow table? the OVS flow table? 17:53:12 I'm not sure if we'll be able to leverage any of it, but AT&T is in the process of open sourcing some code we did for a number of OvS manipulations including flow steering 17:53:25 pcarver: that is in the OVS Agent on the compute node in the data path if I understand your quesiton correctly 17:53:31 s3wong: Yes, I'm asking about the actual mechanics of the implementation 17:53:37 pcarver: is you can share that would be useful 17:53:40 if 17:54:24 pcarver: and the code you guys will open-source is not OpenStack related code? 17:54:28 LouisF: I'll share once we get it out in the open. It's software that started out in AT&T Labs research for QoS and was subsequently enhanced for flow steering and some work has been looked at for port mirroring 17:54:57 pcarver: great 17:55:15 s3wong: correct. It was built to work with OpenStack (uses Keystone and Neutron APIs) but manipulates OvS independently of Neutron. 17:55:42 We just recently got VP approval to open source it, but it needs to be cleaned up before release 17:55:56 mostly on the documentation side from what I understand 17:56:02 I aasume that in AT&T codes, the OVS Driver and OVS Agent will coordinate together and program the OVS flow table? 17:56:07 can it operate on conjunction with neutron control of ovs? 17:56:17 in conjunction 17:56:30 pcarver: sounds good. Looking forward to seeing it out in the open. Please share with us the github link (I assume you guys will put it on github) once it become available. Thanks! 17:56:43 cathy_: I haven't seen exactly what's being released. The original implemenation used Floodlight, but there have been changes since then. 17:57:00 pcarver: Ok. 17:57:15 I don't think we would leverage it as a whole, but maybe we can gain something from it. I'm talking to the people who developed it. 17:57:39 time is up. Could everyone please go to the new spec patch to review it? 17:57:55 I mean review it as soon as possible 17:57:59 LouisF: For the limited use we're using it for, yes. 17:58:37 cathy_ okay , sure ! 17:59:10 Thanks everyone for joining the meeting. By for now 17:59:12 bye 17:59:18 thanks. bye! 17:59:19 bye 17:59:19 bye 17:59:45 bye 18:00:12 #endmeeting