17:02:07 <cathy_> #startmeeting service_chaining
17:02:08 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:02:12 <openstack> The meeting name has been set to 'service_chaining'
17:02:19 <s3wong> hello
17:02:21 <cathy_> hi everyone
17:02:22 <LouisF> hi
17:02:28 <pcarver> hi
17:02:55 <Mohankumar__> hi
17:02:56 <vikram> hi
17:03:04 <cathy_> good let's start
17:03:51 <cathy_> 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 <LouisF> #link https://review.openstack.org/#/c/204695
17:04:26 <LouisF> this adds detail on the url and resource endpoints
17:04:49 <cathy_> sc68cal: are you there?
17:05:00 <s3wong> LouisF: may want to just add sc68cal as reviewer, so it would be on his review queue
17:05:16 <cathy_> s3wong: good point. will do
17:05:29 <sc68cal> looking now
17:06:07 <pcarver> 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 <cathy_> 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 <vikram> cathy_: will review it
17:06:40 <sc68cal> I have an item
17:06:45 <cathy_> pcarver: thanks.
17:06:50 <cathy_> vikram: thanks
17:07:10 <sc68cal> Can we get some cross-collaboration on this spec? https://review.openstack.org/186663
17:07:15 <s3wong> sc68cal: that was fast :-)
17:07:32 <cathy_> sc68cal: I am looking at that spec.
17:07:53 <sc68cal> 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 <s3wong> sc68cal: sure
17:08:12 <sc68cal> https://review.openstack.org/186663 - I would like to see just one API for forwarding and forwarding-like things
17:08:36 <pcarver> interesting. That does seem like it overlaps
17:08:47 <sc68cal> 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 <cathy_> 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 <s3wong> sc68cal: we do also --- the tradeoff however is that networking-sfc would have a dependency on this to land
17:09:20 <vikram> cathy_: this is another spec..
17:09:22 <cathy_> sc68cal: if you look at previous meeting logs, we have discussion on that and community consensus on that
17:09:43 <vikram> sc68cal: i feel this spec is unrelated to service function chaining
17:10:01 <vikram> 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 <LouisF> vikram: agree - it addresses filtering but not service chaining
17:10:34 <cathy_> sc68cal: Sorry this seems another spec, not the one Yuji posted on flow classifier. Sorry for the confusion
17:10:56 <vikram> sc68cal: what is your felling?
17:11:00 <vikram> *felling
17:11:08 <LouisF> the common classifier spec is https://review.openstack.org/#/c/190463/
17:11:15 <vikram> i am really bad at spellings :-)
17:11:25 <s3wong> 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 <pcarver> 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 <pcarver> Especially if the two can interact in unpredictable ways
17:12:19 <vikram> pcarver: i agree..
17:12:23 <sc68cal> 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 <vikram> sc68cal: hmmmm
17:13:20 <pcarver> 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 <vikram> sc68cal: we can hold it unless we have a definite usecase which could not be resolved using service function chaining
17:13:36 <cathy_> sc68cal: +1
17:13:42 <pcarver> as opposed to two unrelated things that appear similar to the user
17:14:04 <LouisF> sc68cal: the sfc is more general than the forwarding spec
17:14:30 <LouisF> its functionality can be covered by the sfc spec
17:14:36 <vikram> sc68cal, pcarver: I agree, service function chaining can achieve the use case defined in forwarding spec
17:15:06 <pcarver> 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 <vikram> How about holding it unless we have a definite usecase which could not be resolved using service function chaining
17:15:28 <s3wong> 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 <cathy_> vikram:agree with you. Would you like to talk with Yuji on that ?
17:15:32 <vikram> pcarver: I believe it can
17:15:36 <LouisF> pcarver: yes I think that can be done
17:16:03 <sc68cal> yeah I mean I could be stupid but the forwarding API is basically just a chain of 1
17:16:11 <vikram> cathy_: We can put our concerns over the etherpad link shared for this spec
17:16:14 <sc68cal> and BTW - fwaas is going to be a chain of 1
17:16:26 <vikram> https://etherpad.openstack.org/p/forwarding-rule
17:16:27 <sc68cal> if we're inserting a firewall between an instance and the rest of the network
17:16:52 <sc68cal> I had hoped to consume SFC, to look into making fwaas more flexible
17:17:00 <vikram> sc68cal:+++100
17:17:41 <pcarver> sc68cal: +1, security functions are a primary example of the reason for SFC, although not all chained functions are firewallish
17:17:55 <jwarendt> +1
17:18:27 <cathy_> So we all agree that the service chain API can cover the functionality needed in https://review.openstack.org/#/c/186663/
17:18:41 <LouisF> +1
17:18:58 <pcarver> 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 <sc68cal> pcarver: agreed
17:19:42 <cathy_> #agreed the service chain API can cover the functionality needed in https://review.openstack.org/#/c/186663/
17:21:16 <cathy_> So how should we make sure there is no duplicate API? Maybe Vikram can communicate this with Yuji? Suggestion?
17:22:13 <sc68cal> 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 <vikram> cathy_: sure.. i have posted a comment on the spec.. will try to catch him tomorrow over IRC as wekk
17:22:45 <cathy_> sc68cal: agree.
17:23:24 <pcarver> 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 <cathy_> #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 <pcarver> It may be that 186663 shouldn't just be abandoned, but revised to be based on SFC
17:24:33 <cathy_> #action: Vikram try to catch him tomorrow over IRC and pass our consensus to him, get his input.
17:25:33 <cathy_> pcarver: OK with me . You may want to post that suggestion to that spec
17:25:45 <s3wong> pcarver: but you are still advocating that the forwarding-rules/classifier effort be done on Neutron repo?
17:26:21 <pcarver> s3wong: Not advocating anything specific yet. I haven't read the 186663 spec yet.
17:26:34 <pcarver> cathy_: I will review that spec and post my thoughts
17:27:21 <cathy_> pcarver: good. thanks. I think the key is not to have duplicate APIs to confuse the community.
17:27:50 <cathy_> sc68cal: Thanks for starting this discussion topic!
17:28:03 <sc68cal> np
17:28:07 <cathy_> any other topic you folks would like to discuss?
17:29:01 <pcarver> 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 <pcarver> The top results tend to show up obsolete information
17:29:41 <pcarver> Louis' abandonded spec for example, and a wiki with old info and an outdated document
17:29:59 <pcarver> e.g. https://wiki.openstack.org/wiki/Neutron/ServiceInsertionAndChaining
17:30:08 <s3wong> pcarver: yeah, the top result (https://wiki.openstack.org/wiki/Neutron/ServiceInsertionAndChaining) has been obsolete since Juno...
17:30:27 <pcarver> I'm going to start doing a little editing, but it would be good if other people took a look too
17:30:37 <cathy_> pcarver: not sure how to fix that? Any clue?
17:30:42 <LouisF> that work was started some ago and was abandoned
17:31:03 <pcarver> The wiki is easy. Launchpad also. Gerrit I'm not sure
17:31:16 <pcarver> Anybody good with Gerrit URLs?
17:32:06 <cathy_> pcarver: so you are going to fix the search result of wiki and launchpad?
17:32:36 <cathy_> pcarver: I will talk with you offline about how to fix that. I would like to learn:-)
17:32:43 <pcarver> 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 <s3wong> cathy_: I think pcarver is going to remove the wiki and launchpad pages :-)
17:33:08 <s3wong> Google search / cache, we can't do much about...
17:33:23 <pcarver> anybody know the correct URL to replace that so that it shows the new spec rather than the abandoned one?
17:33:48 <cathy_> pcarver: I can fix that
17:34:27 <cathy_> #action cathy modify the BP to reference the new spec
17:34:45 <cathy_> s3wong: :-)
17:35:01 <cathy_> how is the dependency issue of the Neutron SC client on the base code going? Vikram: any update?
17:35:13 <vikram> resolved:-)
17:35:21 <cathy_> vikram: Cool !
17:35:22 <vikram> thanks to amotoki
17:35:25 <Mohankumar__> yes , We got solution for base dependecency issue( by adding requirements in requirements.txt)
17:35:41 <s3wong> pcarver: https://review.openstack.org/#/c/192933/
17:35:43 <vikram> we need to add something in test-requirement.txt
17:35:45 <cathy_> Mohankumar__: great. that simple :-)
17:36:11 <Mohankumar__> cathy_ yes :)
17:36:25 <pcarver> s3wong: That URL is in there, but it's a different view than the other one
17:37:01 <pcarver> s3wong: That URL is listed as "Addressed by" whereas the incorrect URL is listed as "Gerrit topic"
17:37:26 <pcarver> Oh, I think I just figured it out
17:37:43 <pcarver> Our topic is someone confusingly called "initial-manifesto"
17:38:08 <pcarver> the incorrect one is called neutron-api-extension-for-service-chaining
17:38:10 <cathy_> pcarver: ?
17:38:23 <s3wong> pcarver: yeah, I noticed that a while back :-)  was wondering what the heck does that mean...
17:38:51 <s3wong> what is the official "Topic"?
17:39:04 <cathy_> pcarver: could you clarify what you are talking about?
17:39:35 <pcarver> 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 <pcarver> 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 <pcarver> cathy_: Note that there are two URLs, one "Gerrit topic" and one "Addressed by"
17:41:08 <pcarver> The "Gerrit topic" is actually a dynamic query that hits on Louis' abandoned changed
17:41:23 <s3wong> yeah, so fixing the Gerrit topic link should suffice
17:41:26 <LouisF> pcarver: will fix
17:41:27 <cathy_> So we need to change the Gerrit topic to the new one, right? We cna manually change that I assume?
17:41:29 <pcarver> The Addressed by is a correct link to our merged spec
17:42:06 <pcarver> 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 <pcarver> it's just a little weird because the actual topic name isn't as natural
17:43:30 <cathy_> pcarver: So we might need to make the topic name natural
17:43:45 <cathy_> otherwise it is confusing.
17:43:52 <pcarver> cathy_: I'm not sure it's worth changing
17:43:54 <s3wong> what's wrong with initial-manifesto?   :-)
17:44:12 <pcarver> I was just commenting that it's a bit odd
17:45:12 <cathy_> s3wong: what is meant by initial-manifesto? I did not pay attention to this before
17:45:50 <s3wong> cathy_: look at the "Topic" field at the gerrit for the API spec (https://review.openstack.org/#/c/192933/)
17:46:07 <pcarver> 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 <s3wong> "initial-manifesto"
17:47:26 <LouisF> pcarver: ok
17:47:58 <cathy_> 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 <cathy_> #action Louis update the BP to refer to both specs which have all the reviews
17:48:41 <pcarver> 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 <cathy_> pcarver: Thanks!
17:49:29 <cathy_> #action pcarver updates the wiki to point to the blueprint and the API spec
17:50:33 <cathy_> Just an update on the API implementation. We are almost done and will post it for review mid next week.
17:51:22 <cathy_> Any other issues for discussion?
17:51:26 <pcarver> cathy_: roughly where in the code are you working on the implementation?
17:51:52 <cathy_> pcarver: not sure what you mean?
17:52:09 <s3wong> cathy_: may be worthwhile to put unfinished patches on gerrit for early review (with workflow set to -1)
17:52:29 <pcarver> I mean where is the flow table manipulation happening?
17:52:46 <cathy_> pcarver: We will add SFC API handling and DB codes in the Neutron Server
17:53:09 <s3wong> pcarver: flow table? the OVS flow table?
17:53:12 <pcarver> 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 <cathy_> pcarver: that is in the OVS Agent on the compute node in the data path if I understand your quesiton correctly
17:53:31 <pcarver> s3wong: Yes, I'm asking about the actual mechanics of the implementation
17:53:37 <LouisF> pcarver: is you can share that would be useful
17:53:40 <LouisF> if
17:54:24 <s3wong> pcarver: and the code you guys will open-source is not OpenStack related code?
17:54:28 <pcarver> 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 <LouisF> pcarver: great
17:55:15 <pcarver> s3wong: correct. It was built to work with OpenStack (uses Keystone and Neutron APIs) but manipulates OvS independently of Neutron.
17:55:42 <pcarver> We just recently got VP approval to open source it, but it needs to be cleaned up before release
17:55:56 <pcarver> mostly on the documentation side from what I understand
17:56:02 <cathy_> 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 <LouisF> can it operate on conjunction with neutron control of ovs?
17:56:17 <LouisF> in conjunction
17:56:30 <s3wong> 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 <pcarver> 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 <cathy_> pcarver: Ok.
17:57:15 <pcarver> 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 <cathy_> time is up. Could everyone please go to the new spec patch to review it?
17:57:55 <cathy_> I mean review it as soon as possible
17:57:59 <pcarver> LouisF: For the limited use we're using it for, yes.
17:58:37 <Mohankumar__> cathy_ okay , sure !
17:59:10 <cathy_> Thanks everyone for joining the meeting. By for now
17:59:12 <LouisF> bye
17:59:18 <s3wong> thanks. bye!
17:59:19 <jwarendt> bye
17:59:19 <Mohankumar__> bye
17:59:45 <vikram> bye
18:00:12 <cathy_> #endmeeting