17:00:14 <cathy_> #startmeeting service_chaining
17:00:15 <openstack> Meeting started Thu Jul  2 17:00:14 2015 UTC and is due to finish in 60 minutes.  The chair is cathy_. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:20 <openstack> The meeting name has been set to 'service_chaining'
17:00:28 <cathy_> hi everyone
17:00:50 <vikram_> hi
17:00:59 <cathy_> vikram_: hi
17:01:06 <vikram_> cathy: hi
17:01:40 <xgerman> hi
17:01:53 <cathy_> let's wait for a little bit for others to join.
17:01:59 <cathy_> xgerman: hi
17:02:24 <Swami> hi
17:02:32 <cathy_> Swami: hi
17:03:04 <cathy_> OK, let's start now.
17:03:56 <cathy_> here are some topics I have in mind for today's discussion. 1.	Service chain spec status https://review.openstack.org/#/c/192933/5 2.	Repository for Neutron client code to support service chain project 3.	Vikram update on discussion with Yuji regarding flow classifier included in SFC spec and implemented in SFC project as a independent module which can be used in the future by other features
17:04:16 <cathy_> any other topic ?
17:04:55 <cathy_> #topic Service chain spec status https://review.openstack.org/#/c/192933/5
17:05:19 <cathy_> s3wong: hi
17:05:30 <s3wong> cathy_: hello
17:05:41 <jwarendt> hi
17:06:05 <cathy_> many people have given comments to the spec and the spec has been updated many versions to address those comments.
17:06:15 <cathy_> jwarendt: hi
17:07:40 <cathy_> In our last last IRC meeting, we agreed that we should finalize the spec on June 24. Now we have given it one more week. So it is now time to merge the spec. OK with everyone?
17:08:27 <cathy_> Anyone has different opinion?
17:08:51 <s3wong> cathy_: let's do it :-)
17:08:59 <Swami> Let us wait till the end of this week.
17:09:07 <amotoki_> cathy_: one question. do you plan to update the current version? inline answers are hard to be tracked later.
17:09:07 <pcarver> This spec only addresses "serial" chains, right? I don't see a way of scaling out in parallel.
17:09:08 <Swami> or shall we go ahead and merge it right now.
17:09:50 <cathy_> amotoki_: it is already updated
17:09:51 <amotoki_> i don't oppose to merge itself, but just would like to clarify.
17:10:25 <amotoki_> cathy_: woops.  got it.The above link was old :-(
17:10:29 <s3wong> Swami: unless you think we are going to comment on it during the ID4 weekend...
17:10:40 <cathy_> pcarver: yes, its scope is serial chain if we mean the same by "serial"
17:10:44 <pcarver> I'd like to see scale out, i.e. multiple VMs in parallel at a given link in the chain, but I could see how that might need to be a second phase and a later addition to the spec.
17:11:13 <Swami> no I did see there are some comments from vikram. So if we are going to roll it, why not give it another couple of days, so that we can collect all the input and do a single roll.
17:11:55 <vikram_> Swami: My comments are more about semantics and elaboration.. design wise i am fine.
17:12:20 <Swami> vikram_: yes I understand, but still should we not roll it address those comments.
17:12:40 <vikram_> Swami: Ok
17:12:44 <Swami> vikram_: I am not saying that there is a major change that need to happen.
17:12:47 <pcarver> cathy_: I think so. This approach to service chaining assumes that all the traffic in the chain can be handled by every VM in the chain. No support for splitting the load among VMs.
17:13:14 <Swami> pcarver: can't we extend that use case later.
17:13:34 <vikram_> Swami: Ok; +1
17:13:44 <pcarver> pcarver: I'm fine with adding it later as long as there's nothing that would prevent it.
17:13:47 <Swami> pcarver: we don't wan't to address too many use cases and then not able to complete the implemetation in time.
17:13:54 <pcarver> Swami: I agree
17:14:03 <Swami> ok then let us proceed.
17:14:11 <amotoki_> question from newcomer to this meeting. Is there any pointers which describe the scope of the initial work?
17:14:17 <pcarver> Swami: better to get a first iteration out as long as it doesn't preclude later expansion
17:14:32 <cathy_> Swami: so you are OK with that we ask for core members to approve it, right?
17:14:38 <amotoki_> my question looks similar from pcarver.
17:14:58 <cathy_> pcarver: No, it does not preclude later extension.
17:15:06 <Swami> cathy_:=1
17:15:16 <Swami> cathy_:+1
17:15:48 <cathy_> pcarver: agree with you that we'd better get the first iteration out, otherwise we will never start:-)
17:16:42 <pcarver> cathy_: +1
17:16:42 <amotoki_> cathy_: +1. One suggestion is to document the scope of the first iteration.
17:16:47 <s3wong> cathy_: +1
17:16:50 <vikram_> cathy, pcarver :+1
17:17:06 <vikram_> amotoki: +1
17:17:36 <amotoki_> by doing so we can avoid the same discussions/questions again and again.
17:17:55 <vikram_> amotoki: bingo..
17:18:10 <jwarendt> +1
17:18:11 <vikram_> :)
17:18:28 <cathy_> OK, let's do a formal vote (sorry you have to do again). I will type #startvote, then you type #vote
17:18:37 <cathy_> #startvote yes or no
17:18:38 <openstack> Unable to parse vote topic and options.
17:18:50 <s3wong> openstack doesn't like it :-0
17:18:58 <xgerman> starvote question? Yes or No
17:19:18 <cathy_> oops, it does not work. OK, I guess these +1 counts.
17:19:28 <Swami> cathy_: yes +1 counts
17:19:34 <s3wong> or just +1 on the gerrit itself?
17:19:43 <vikram_> +1
17:19:49 <cathy_> Swami: good :-)
17:19:53 <xgerman> I think we have consensus
17:20:25 <cathy_> s3wong: yes, like your suggestion. Please everyone go to the Gerrit spec to give +1
17:20:35 <s3wong> cathy_: just voted
17:20:39 <cathy_> xgerman: yes
17:20:48 <cathy_> cool, let's go to next topic
17:21:06 <amotoki_> I think we can check api spec and document the first iteration scope in separate reviews.
17:21:42 <amotoki_> so we can go forward.
17:21:59 <cathy_> amotoki_: yes
17:22:46 <cathy_> #agreed  everyone agreed (give +1)  that the spec is now ready to be approved by the core members,  https://review.openstack.org/#/c/192933/5
17:23:02 <cathy_> #topic 2.	Repository for Neutron client code to support service chain project
17:23:32 <cathy_> vikram and Swami : any input on this?
17:23:51 <Mohankumar_> hi cathy
17:24:12 <vikram_> cathy: i have checked other repo's, they just keep the updated files only.
17:24:16 <cathy_> Mohankumar_: hi
17:24:18 <Swami> cathy_: as I mentioned before we should be using the same repo "networking-sfc" for any client side changes that are specific to sfc.
17:24:37 <Mohankumar_> shall we split cli into two parts
17:24:45 <Swami> cathy_: here is an example.
17:24:54 <Mohankumar_> [1] port chain [2] FLowfliter
17:25:03 <amotoki_> I agree with Swami as the main maintainer of neutroncleint.
17:25:04 <Swami> cathy_: #link https://github.com/openstack/networking-l2gw/tree/master/networking_l2gw/l2gatewayclient
17:25:09 <vikram_> https://github.com/openstack/networking-bgpvpn/tree/master/networking_bgpvpn/neutronclient/neutron/v2_0/bgpvpn
17:25:33 <Swami> cathy_: the l2gateway folks did similar thing in the networking-l2gw repo,so we should follow the same model.
17:25:33 <amotoki_> neutronclient has plugin mechanism and you can define a class of sfc command lines.
17:25:48 <amotoki_> another option is the way l2gw folks does.
17:25:57 <amotoki_> they have separate CLI.
17:26:17 <Swami> amotoki_: which one do you prefer, the former or the later
17:26:38 <amotoki_> I don't have a strong opinion on this.
17:26:42 <cathy_> Mohankumar_: yes, let's split the CLI into two parts
17:26:48 <pcarver> we want to share the flow classifier with other functions such as QoS, right?
17:26:57 <amotoki_> personally I am wondering OSC integration but it is a slow progress.
17:27:17 <vikram_> Swami, amotoki: My confusion is how about the base files which will need changes
17:27:42 <Swami> vikram_: when you say base files are you talking about the "shell.py".
17:27:42 <cathy_> pcarver: yes, so let's split the CLI into two parts , one for port chain , another for flow classifier
17:27:43 <vikram_> eg: client.py / shell.py
17:27:49 <amotoki_> vikram_: base files? could you elaborate more?
17:28:03 <vikram_> ex: shell.py
17:28:07 <pcarver> cathy_: good, that makes sense
17:28:20 <amotoki_> vikram_: let me find a link.
17:29:03 <amotoki_> I think the contrib mechanism works: https://github.com/openstack/python-neutronclient/tree/master/neutronclient/neutron/v2_0/contrib
17:29:41 <amotoki_> I don't cover the detail now. you can reach me later.
17:30:05 <Mohankumar_> I was splited cli s  and submitted neutron client changes [1] https://review.openstack.org/#/c/197014/ [2]https://review.openstack.org/#/c/197040/
17:30:17 <vikram_> amotoki: thanks for sharing but my question is we might need some common files in the repo already
17:30:58 <cathy_> Mohankumar_: thanks. Everyone please review the neutron client changes.
17:31:13 <amotoki_> Mohankumar_: let me check later
17:31:20 <vikram_> otherwise when we raise a patch for review then diff for common files like shell.py and client.py will be not accurate
17:31:47 <vikram_> amotoki_: you got my question?
17:31:53 <Mohankumar_> thansk Cathy_ ,amotoki_
17:32:30 <amotoki_> vikram_: which one? if it s about shell.py, I think I answered.
17:32:48 <amotoki_> vikram_: the contrib mechanism. I can share more detail later.
17:33:22 <vikram_> amotoki_: ok.. I will take this offline
17:33:27 <cathy_> Swami: what's your input about vikram's quesiton on "otherwise when we raise a patch for review then diff for common files like shell.py and client.py will be not accurate"?
17:33:45 <vikram_> eq: https://review.openstack.org/#/c/197014/1/networking_sfc/python-neutronclient/neutronclient/shell.py
17:34:10 <Swami> cathy_: I think vikram_ can discuss this with amotoki_ since he might be able to provide the right direction since he is the core on the neutron_client.
17:34:28 <Brian__> I think client code should be in different repository from network-sfc:-)
17:34:40 <amotoki_> neutron client does not have a separete core team
17:34:41 <vikram_> Swami, cathy_: ok will discuss with amotoki_
17:35:09 <cathy_> great.
17:35:32 <cathy_> #action vikram discuss with amotoki_ about neutron client repository
17:36:03 <s3wong> yeah, normally client is in a different repo, but maintained by the same set of core
17:36:07 <cathy_> now can we go to next topic?
17:36:24 <Mohankumar_> i need json resposes to verify my horizon code
17:37:03 <Mohankumar_> any can help on this ?
17:37:15 <amotoki_> Mohankumar_: is it a topic for open discussion? if so we can go to the next topic in the agenda.
17:37:18 <vikram_> cathy_: Mohankuamr_ need neutron-server changes for verifying horizon changes
17:37:31 <cathy_> Mohankumar_: OK, Brian can work with you offline on that, OK with you?
17:37:47 <Mohankumar_> okay cathy_
17:38:02 <cathy_> vikram_: I will work with Mohankumar_ on the server side
17:38:14 <vikram_> cathy_:thanks
17:38:21 <cathy_> #topic 3.	Vikram update on discussion with Yuji regarding flow classifier included in SFC spec and implemented in SFC project as a independent module which can be used in the future by other features
17:39:24 <s3wong> :-)
17:39:29 <cathy_> :-)
17:39:36 <vikram_> Yuji agreed that flow classifier and Classifier spec are identical
17:40:03 <Swami> vikram_: but is he going to drop his spec and follow ours.
17:40:34 <Swami> vikram_: if both are the same we need to add our input in his spec and either combine the both into one or else get rid of the other.
17:40:40 <s3wong> vikram_, Swami: yeah, I thought cathy_ mentioned classifier definition would be part of SFC spec?
17:40:58 <vikram_> Swami: Yuji's only concerns is that the flow classifier spec is proposed in SFC and can it be applicable to neutron?
17:40:58 <cathy_> vikram_: thanks for the update.
17:41:37 <cathy_> Swami: since flow classifier is a must for our SFC feature, we have included it in the SFC spec.
17:41:41 <cathy_> s3wong: yes
17:41:43 <Swami> vikram_: so in that case, if we want to make the Flow classifier generic, then we should follow Yuji's spec and make it generic so that it can be extended later.
17:42:13 <vikram_> Swami: +!
17:42:24 <amotoki_> Swami: +1
17:42:32 <s3wong> vikram_: and if we make classifier generic, it may need to get into Neturon repo, and SFC would have a dependency on this development
17:42:37 <vikram_> Swami: I feel the current proposal is also generic
17:42:42 <cathy_> Swami: the flow classifier in our spec is also generic since they are exactly the same. Implementing it inside SFC project does not mean it can not be done in a generic way and be used by other features.
17:43:02 <Swami> s3wong: yes if we make it generic then we need to dependent on that spec.
17:43:19 <amotoki_> SFC is a first consumer of flow classifier and we first need to clarify what is needed for SFC
17:43:24 <vikram_> s3wong: in the end sfc developed code will also be merged to neutron :)
17:43:30 <Swami> vikram_: cathy_: I think we are going in circles.
17:43:34 <amotoki_> and then discuss how to make it more general.
17:44:06 <cathy_> s3wong: Yes, that is a key point. We do not like to create a dependency on another new project.
17:44:11 <s3wong> vikram_: in that case, we may the spec part of networking-sfc spec, and have the development done in network-sfc repo
17:44:33 <vikram_> s3wong: +1
17:44:34 <amotoki_> Options are (1) we discuss the generic model first or (2) we conclude what is required as SFC project.
17:44:52 <cathy_> s3wong: +1
17:45:01 <Swami> cathy_: vikram_: my concern is if we don't get to consensus on the flow classifier today with Yuji then it would end up in two different implementations.
17:45:32 <cathy_> amotoki_: it is required ad SFC project, no doubt. Without it we cna not say we deliver the SFC feature
17:45:44 <s3wong> amotoki_: I think given that SFC development is slated (to get something done by) Liberty, we may need to first get a classifier that is more specific to SFC first before iterating it to be generic
17:45:50 <amotoki_> Swami: what is the key difference of two diff impls?
17:45:57 <vikram_> Swami: this concern is already raised via https://etherpad.openstack.org/p/flow-classifier
17:46:14 <Swami> amotoki_: vikram_ says that it is the same. So my request is to make it as a single spec.
17:46:23 <cathy_> I think s3wong are amotoki_ are saying the same thing and I agree with their point.
17:46:55 <vikram_> amotoki_: i have read both the spec and they are same.. even yuji has admitted that
17:48:16 <amotoki_> i think there are two points: API perspective and implementation.
17:48:27 <cathy_> vikram_: so I don't think we need to create a separate spec which address the same as what is in our SFC spec.
17:48:28 <vikram_> Swami: I have also asked Kyle to help us on this soon.
17:48:28 <s3wong> vikram_: in that case, let's put the classifier spec in networking-sfc, so we have a specific use case, and can discuss/reach-consensus accordingly; now it is filed against neutron-specs
17:48:44 <amotoki_> let me check. I think I haven'ts spent enought time to review them both.
17:49:12 <vikram_> s3wong: no need of separate spec..
17:49:22 <vikram_> i feel the same spec is okay
17:49:40 <s3wong> vikram_: as you said earlier, things in networking-sfc will eventually merge into Neutron anyway
17:49:53 <vikram_> what i meant was just we develope code as a generic model as per the spec
17:50:03 <amotoki_> i think there are two points: API perspective and implementation. let me check both specs. I will reach yuji tomorrow morinig.
17:50:14 <s3wong> vikram_: so in that case, we can first iterate the classifier spec within the SFC team
17:51:36 <vikram_> s3wong: i am not sure on this.. may be cathy/Swami/amotoki_ will answer it better
17:52:36 <Swami> vikram_: yes I agree with s3wong that we can bring everything into the SFC spec under networking-sfc and then proceed, so that we don't have any dependency and everything is confined within this team.
17:52:37 <amotoki_> I think it is better to start in SFC team as long as the requriements are clarified.
17:52:53 <cathy_> The bottom line is that we need the flow classifier spec API and implementation in our SFC feature. Without it we can not deliver the SFC feature.
17:53:28 <cathy_> I agree with Swami and amotoki_ and s3wong
17:54:16 <cathy_> So it seems the consensus is to have the flow classifier in the SFC spec and proceed.
17:54:26 <vikram_> cathy_: so what's will be the next step on this?
17:54:53 <amotoki_> one important point is to clarify the requirements for classifier from SFC perspective in our discussion.
17:55:10 <cathy_> vikram_: let's proceed with the SFC spec and start coding as fast as we can with high quality:-)
17:55:16 <amotoki_> if it is claer, we can discuss more general modle easier.
17:56:07 <cathy_> amotoki_: yes, agree with you. The requirements of classifier for SFC has been addressed in the SFC spec itself.
17:57:06 <cathy_> It is needed to associate a specific tenant's flow with a service chain that the flow will be steered through to get the sequence of services specified by the chain.
17:57:33 <s3wong> cathy_: in fact, the classifier definition is already in the SFC API spec, right?
17:57:41 <cathy_> Good discussion.
17:57:44 <s3wong> cathy_: so really no need for another spec, honestly
17:57:56 <cathy_> s3wong: yes, exactly
17:58:12 <s3wong> cathy_: yes --- time to implement :-)
17:58:41 <nbouthors> What about support for application Id ? It is not in the spec yet, but ODL SFC has it.
17:58:54 <vikram_> I am not sure if i can ask this question now.. how we are planning to implement flow-classifier?
17:59:03 <cathy_> s3wong: creating another spec duplicating the exact same content will cause more confusion than benefit, just as we were confused and spent so much time inline and offline doing comparison etc.
17:59:32 <s3wong> cathy_: +1 --- in the context of networking-sfc, it really isn't necessary
17:59:38 <cathy_> vikram_: let's discuss the implemenation in next meeting
17:59:50 <cathy_> nbouthors: sorry time is up. let's discuss it offline
17:59:54 <vikram_> cathy_:+1
18:00:20 <vikram_> bye
18:00:25 <jwarendt> thanks
18:00:27 <Brian__> bye
18:00:28 <s3wong> fast one hour
18:00:31 <cathy_> #agreed the flow classifier will be part of the SFC spec and implemented inside the SFC project
18:00:37 <vikram_> yes...
18:00:38 <nbouthors> bye
18:00:41 <amotoki_> thanks. I try to be here next week or later. it is a bit late in japan :-(
18:00:44 <Mohankumar_> bye
18:00:54 <cathy_> thanks everyone. Bye now.
18:00:56 <s3wong> amotoki_: good to have you here though!
18:00:59 <Swami> bye
18:01:03 <s3wong> Thanks. Bye!
18:01:08 <vikram_> amotoki_: nice to have you here:)
18:01:09 <cathy_> amotoki_: thanks for joining!
18:01:24 <cathy_> #endmeeting