17:00:12 <cathy_> #startmeeting service_chaining
17:00:13 <openstack> Meeting started Thu Feb 25 17:00:12 2016 UTC and is due to finish in 60 minutes.  The chair is cathy_. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:14 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:17 <openstack> The meeting name has been set to 'service_chaining'
17:00:45 <LouisF> hi cathy_
17:00:50 <cathy_> hi LouisF
17:00:55 <fsunaval> hi cathy_
17:01:03 <cathy_> hi fsunaval
17:01:15 <LouisF> fsunaval: hi
17:01:36 <fsunaval> Hi LouisF
17:02:00 <vikram_> hi
17:02:03 <cathy_> hi vikram_ johnsom mohankumar_
17:02:06 <mohankumar_> hi
17:02:33 <johnsom> o/
17:02:55 <cathy_> hi minwang2
17:03:11 <minwang2> hi
17:03:56 <cathy_> I have two topics for today. Any topic you would like to discuss today?
17:04:14 <pcarver> hi. I'm in simultaneous voice call.
17:04:25 <cathy_> hi pcarver raddaoui
17:05:51 <cathy_> #topic propose for governance under big tent
17:06:53 <mohankumar_> cathy_ : could you elaborate the topic ?
17:07:19 <cathy_> Given recent discussion on the change of Neutron stadium scope, we are thinking about proposing the SFC project under OpenStack Big Tent governance
17:07:50 <vikram_> cathy_: means it won't be no longer neutron-official project?
17:08:30 <johnsom> Almost every project under neutron will no longer be an "neutron-official project".
17:08:40 <cathy_> mohankumar_: Last few weeks, there have been heated discussion on Neutron big stadium projects. Basically all big stadium projects are not out of Neutron governance
17:08:48 <johnsom> https://review.openstack.org/#/c/281628/
17:08:55 <johnsom> #link https://review.openstack.org/#/c/281628/
17:09:26 <cathy_> johnsom: thanks for posting the links!
17:10:11 <pcarver> There seems to be a circular line of reasoning that only projects worked on by "the Neutron team" will be part of Neutron, but the definition of "the Neutron team" is "the people who work on projects that are part of Neutron"
17:10:34 <LouisF> pcarver: +1
17:10:42 <vikram_> ok
17:11:57 <vikram_> I can find Kuryr move to big tent also
17:11:59 <vikram_> https://review.openstack.org/#/c/280522/
17:12:10 <cathy_> Yes, SFC and L2GW seem to be the last few that people are still debating, but given that Neutron is being stripped to a bare minimum according to the patch, we are thinking about applying for governance under OpenStack big tent.
17:12:15 <LouisF> the discussion is around the overlap of neutron core members involved in sub-projects
17:12:57 <pcarver> So basically the "big tent" still exists but the "Neutron stadium" doesn't
17:13:35 <cathy_> Yes, so anyone has objection to applying networking-sfc for governance under OpenStack Big Tent?
17:13:47 <pcarver> So if SFC isn't a core part of Neutron we should get it categorized as a distinct "big tent" project
17:13:51 <amotoki> surprisingly enough I am still waking up.  kuryr is a bit different situation. it is a consumer of neutron API.
17:14:08 <pcarver> I suppose that means we need to come up with a cooler name than networking-sfc
17:14:28 <cathy_> pcarver: yes
17:14:35 <cathy_> amotoki: welcome back!
17:14:40 <amotoki> hehe
17:14:51 <vikram_> pcarver: +1
17:14:59 <pcarver> So everyone start thinking analogies: Cinder is to block as ? is to chain
17:14:59 <LouisF> dragonflow which is very closely related to neutron is also now in big tent
17:15:20 <cathy_> amotoki: are you OK with applying for big tent?
17:15:25 <vikram_> LouisF: Yup.. https://review.openstack.org/#/c/277153/
17:15:49 <amotoki> cathy_: I am not sure on this.
17:16:29 <amotoki> kuryr is a consumer of neutorn api and dragonflow is one of back-ends of neutron.
17:16:59 <cathy_> amotoki: if not big tent, what other governance given existing Neutron inclusion result
17:17:09 <amotoki> i haven't followed the dissussion in the reviews of bit-tent inclusion of kuryr and dragonflow.
17:17:24 <amotoki> cathy_: i understand your concern.
17:18:11 <amotoki> so I don't have a strong opinion just now...
17:18:15 <pcarver> amotoki: I strongly feel that SFC (and BGPVPN) should be "part of Neutron" because Neutron should own the vendor/backend independent APIs. But there's a strong sentiment that Neutron should be defined by the list of people who contribute to a certain subset of networking functionality.
17:18:49 <amotoki> pcarver: yeah, i know it.
17:19:03 <vikram_> pcarver: +1
17:19:12 <vikram_> I also have same feeling
17:19:15 <pcarver> so if the criteria ends up being "who contributes to which repos" then we need to figure out where to place networking-sfc
17:19:31 <amotoki> i wonder how much of contributor overlapping and variety are required for neutron inclusion.
17:20:21 <cathy_> amotoki: pcarver for inclusion of Neutron, I would suggest that we take it to the Neutron channel or the Neutron inclusion patch.
17:20:43 <cathy_> since whatever we discussed here will be have any effect:-)
17:20:57 <cathy_> Now let's come back to the name of the SFC for Big Tent
17:21:05 <pcarver> cathy_: I agree and have posted my comments to the patches, but it keeps coming round to the point of who the contributors are.
17:21:24 <cathy_> pcarver: I know and understand the frustration
17:21:28 <vikram_> IMO, it's a weird requirement
17:21:56 <pcarver> If the contributors to networking-sfc don't also contribute to the repos that constitute the "in Neutron" repos then networking-sfc isn't an "in Neutron" repo
17:22:43 <amotoki> i can be involved in the project, but i am not sure how it helps the project.
17:22:55 <pcarver> of course if the functionality of SFC API were considered a "part of Neutron" then the contributor overlap would be 100% by definition. But it isn't.
17:24:09 <LouisF> pcarver: also if the neutron cores feel they don't have regular insight into the design and governance of networking-sfc
17:24:22 <vikram_> I have a question .... if we have to follow big tent way then do we need to revisit the proposed CLI?
17:24:36 <cathy_> amotoki: you were once very involved in this project:-) Now matter whether it is under Neutron Stadium or OpenStack Big Tent, you are always welcomed to be involved:-)
17:24:44 <amotoki> IMO contributor overlapping is one of big points, but layer overlapping with neutron is also a big point.
17:25:19 <pcarver> amotoki: what exactly do you mean by "layer"?
17:25:27 <cathy_> vikram_: no I don't think so. But we are always open to good suggestion
17:25:46 <pcarver> I do think a high level of modularity should always be an objective regardless of which parts are "in" or "out"
17:25:49 <amotoki> pcarver: (i haven't got an appropriate word)
17:26:06 <s3wong> sorry, very late
17:26:22 <amotoki> pcarver: kuryr is a consumer of neutorn api and dragonflow can be a backend of neutorn, but networking-sfc is not .....
17:26:23 <vikram_> cathy_: I asked this because all our current cli's starts with neutron *
17:26:39 <pcarver> so even if networking-sfc is "in Neutron" I think we're on the right path of plugging in via extension mechanisms that easily allow deployers to add or remove parts
17:26:46 <amotoki> we are covering the same layer (API) as neutron covers.
17:26:53 <cathy_> vikram_: there is always space for API enhancement/extension. Actually for second phase feature support, we will extend the API. Good thing is that the API already has place holders for the extensions
17:27:24 <cathy_> vikram_: OK, I see what you mean. But I guess that is OK. Even we need to change, it is not a big deal
17:27:29 <pcarver> amotoki: I agree on that. I view networking-sfc as extending the functionality of the Neutron API
17:27:46 <vikram_> cathy_: ok .. just a query
17:27:46 <cathy_> s3wong: hi
17:28:02 <amotoki> l2gw, sfc and (possibly bgp stuff) are in the similar situations.
17:28:07 <vikram_> pcarver: +1000
17:28:17 <s3wong> cathy_: sounds like we are talking about moving out of Neutron to the tent?
17:28:31 <LouisF> s3wong: yes
17:29:03 <pcarver> s3wong: more specifically, I think we're saying that if we're not allowed to stay in the stadium we'll have to move to the tent
17:29:21 <s3wong> pcarver, LouisF: I see
17:29:32 <cathy_> s3wong: yes
17:29:49 <cathy_> folks, let's come back to the name of project.
17:29:52 <amotoki> as my hat of an operator i would like to see networking-sfc as a part of neutorn. we don't want to see SFC as a different layer :-(
17:30:11 <vikram_> me to
17:30:11 <LouisF> amotoki: +1
17:30:22 <pcarver> My vote is that things that add new networking APIs to Neutron should be part of Neutron, but the discussion is focussing heavily on who the people are who make up the Neutron team
17:30:34 <s3wong> I agree with pcarver  and amotoki here --- networking-sfc is network plumbing APIs that logically should be part of Neutron
17:30:35 <cathy_> As to Neutron inclusion, I suggest that we take it to the Neutron patch and post your comments there.
17:30:59 <vikram_> cathy_: do you have the link handy?
17:31:07 <johnsom> I think any code that is outside of the core neutron repo is going to be out of neutron
17:31:07 <LouisF> suggest we all post comments on that patch
17:31:16 <amotoki> discussion here thinks me a lot :-)
17:31:28 <cathy_> s3wong: amotoki could you post your comments in that Neutron inclusion patch?
17:31:31 <cathy_> LouisF: +1
17:31:39 <amotoki> cathy_: sure
17:31:54 <johnsom> #link https://review.openstack.org/#/c/281628/
17:31:55 <s3wong> cathy_: sure
17:31:55 <cathy_> vikram_: what link?
17:32:36 <vikram_> johnsom: thanks
17:32:50 <johnsom> cathy_ Sorry, I have to leave the meeting now, I have a conflict.
17:32:53 <vikram_> cathy_: johnsomhas provided ;)
17:33:06 <cathy_> johnsom: thanks
17:33:13 <cathy_> johnsom: sure.
17:33:31 <cathy_> any good name suggestion for this project?
17:34:56 <amotoki> as long as we focus on SFC (service function chaining), networking-sfc sounds good to me. it is clear and describes what we focus on.
17:35:13 <vikram_> +1 for SFC
17:35:13 <cathy_> vikram_: sorry I missed that. What is the name?
17:35:15 <amotoki> isn't it good?
17:35:59 <cathy_> SFC or ServiceFunctionChain?
17:36:00 <vikram_> cathy_: I was looking for #link https://review.openstack.org/#/c/281628/ , johnsom provided
17:36:08 <pcarver> amotoki: It's too descriptive, unlike most OpenStack project names
17:36:10 <vikram_> hmmm
17:36:18 <Farhad> networking-sfc or networking-neutron-sfc or neutron-sfc to specifically say we are neutron based
17:36:37 <LouisF> catenate, catena (italian for chain)?
17:36:45 <amotoki> hmm.. i got your point, but...
17:36:54 <pcarver> I like that Cinder relates to block and Glance to images, but most distinct OpenStack projects have a name that is not directly descriptive of what they do.
17:37:18 <vikram_> SFC might not convey the idea
17:37:26 <cathy_> pcarver: Actually I think it is good to be descriptive
17:37:49 <vikram_> I feel little bit of description would be better
17:37:54 <amotoki> is there any name which assoicate traffic flows? or water flows :-)
17:37:58 <cathy_> Otherwise new people or users will have a hard time searching for info they need
17:38:03 <vikram_> amotoki; ;)
17:38:04 <cathy_> vikram_: +1
17:38:09 <mohankumar_> catena ... lgtm !
17:38:09 <pcarver> cathy_: I do to, but you have to admit that it's not common for OpenStack project names
17:38:54 <cathy_> pcarver: maybe we can give it a descriptive name. If the TC thinks we should have another name, then we can come up with another one
17:39:02 <vikram_> How about "Flow"
17:39:18 <pcarver> cathy_: ok, that's fine with me
17:39:20 <vikram_> I may sound stupid ;)
17:39:30 <pcarver> Actually I kind of like Flow
17:39:41 <cathy_> Given that SFC is discussed in many forums and seems like a very desired feature, we would like people to know that OpenSTack also has support for SFC
17:39:59 <amotoki> we cannot use 'ryu' (which means "water flows" in japanese) :-)
17:40:10 <vikram_> amotoki: hehehe
17:40:22 <amotoki> 'ryu' also means 'dragon'
17:40:27 <cathy_> amotoki: :-)
17:40:33 <LouisF> amotoki: what is chain in japanese?
17:40:35 <amotoki> with different japanese character.
17:41:00 <amotoki> kusari is chain in japanese. hard to pronounce.
17:41:00 <s3wong> amotoki: yes -- -that is my understand via the 'Ryu' character in street fighter (that his name is "dragon")
17:41:15 <amotoki> s3wong: famous game!
17:41:24 <cathy_> how about FlowChain
17:41:46 <amotoki> good candidate
17:41:58 <mohankumar_> cathy_ : +1
17:42:02 <vikram_> Flow somehow holds the notion of chain implicitly..
17:42:14 <pcarver> How about "Foxtail"? It's a type of chain used in jewlery. Sort of like Cinder is a type of block.
17:42:29 <cathy_> vikram_: I don't feel Flow holds the notion of chain.
17:42:41 <LouisF> cathy_: +1
17:42:42 <cathy_> For me Flow just means the traafic flow
17:42:45 <cathy_> traffic flow
17:42:46 <vikram_> cathy_: Different opinions ;)
17:42:54 <cathy_> vikram_: :-)
17:44:38 <fsunaval> cathy: I like FlowChain
17:44:39 <pcarver> Here's an image of a few types of chains https://s-media-cache-ak0.pinimg.com/736x/dc/2a/71/dc2a71cd3a3068c72bc080e694f65752.jpg
17:45:02 <vikram_> Till now, I am also okay with FlowChain
17:45:12 <cathy_> s3wong: pcarver amotoki OK with FlowChain?
17:45:20 <s3wong> cathy_: +1
17:45:25 <amotoki> np for flowchain
17:45:25 <pcarver> vikram_: I'm ok with FlowChain too, just trying to think along the analogy lines of Cinder and Glance
17:46:11 <vikram_> pcarver: go ahead.. we can find something more interesting and attractive ;)
17:46:31 <cathy_> Ok, let's go with FlowChain for now. If anyone think of a better name, we can exchange via email.
17:46:46 <cathy_> amotoki: :-)
17:47:08 <cathy_> #topic features for second phase
17:47:14 <vikram_> this is real fun ... I m loving it
17:47:28 <pcarver> I really like Barbican actually, that's a good name for a security related project. I'd like to come up with something that's unambiguously related to chains
17:47:43 <cathy_> we have touched this a little bit before. Let me summarize them
17:48:08 <cathy_> pcarver: good exercise for you:-)
17:48:35 <LouisF> pcarver: daisy as in daisy-chain?
17:49:08 <pcarver> LouisF: maybe
17:49:33 <LouisF> a bit whimsical ;)
17:50:36 <cathy_> We know that networking-sfc has completed integration with ONOS controller path and OVS driver Path. In second phase we got suggestions to integrate with more SDN Controllers via our southbound common driver API interface so that we can provide a unified API for end users no matter what SDN Controllers is plugged into the southbound
17:51:21 <cathy_> Another area is to support a mixed chain of VM, container, physical devices
17:52:03 <amotoki> in addition, northband integration with projects like tacker (or possible MANO in NFV context)
17:52:18 <cathy_> amotoki: yes
17:52:22 <pcarver> especially physical devices. We need to figure out how much of the problem is solved by l2gw project
17:52:52 <vikram_> pcarver: good point
17:52:53 <LouisF> pcarver: ironic provides the physical device integration
17:53:09 <cathy_> Tacker PTL joined the meeting before and he will work with us for that.
17:53:12 <vikram_> LouisF: so no change for us?
17:53:23 <amotoki> we also need to check the progress of various things which networking-sfc requires
17:53:41 <amotoki> including l2gw and container integration
17:53:44 <LouisF> vikram_: i think phy ports appear as neutron ports
17:53:50 <cathy_> amotoki: yes
17:54:01 <vikram_> LouisF: Ok then no problems for us
17:54:16 <LouisF> vikram_: need to validate
17:54:25 <vikram_> LouisF: Will do
17:54:47 <fsunaval> nested container support in kuryr will help us with integrating containers inside VMs
17:55:38 <vikram_> Better to list all the requirements as per priority...
17:55:54 <vikram_> amotoki: It's very late for you
17:55:57 <LouisF> vikram_: you had a suggestion on classifier enhancements
17:56:04 <cathy_> fsunaval: yes, there is another mechanism called somethinh like VLAN Aware port for adding Neutron port to containers
17:56:04 <vikram_> LouisF
17:56:13 <vikram_> LouisF: Yes
17:57:02 <cathy_> time is up. Let me summarize the second phase features
17:57:27 <vikram_> cathy_: OAM
17:57:44 <mohankumar_> cathy_ : horizon
17:58:04 <LouisF> cathy_: can we discuss in more depth at next meeting
17:58:36 <cathy_> 1. support integration with more backend SDN controllers, 2. support of a mixed chain of VM, container, physical device, 3. integration with upstream Tacker, 4. enhancement of Flow Classifier, 5. Horizon, 6. OAM
17:58:49 <cathy_> wow, a lot on the plate:-)
17:58:51 <vikram_> 7. Heat
17:59:03 <cathy_> vikram_: yes
17:59:17 <LouisF> cathy_: tempest tests
17:59:28 <cathy_> We need to assign people investigating each area and come up with a design spec for review. So please think about which area you have interest and would like to lead the design of that piece.
17:59:29 <vikram_> 1 min remaining ;)
17:59:36 <cathy_> 8. tempest tests
18:00:27 <cathy_> Ok, let's continue the discussion next week. think about which piece you would like to take and lead the design. Thanks everyone. It is a good discussion.
18:00:29 <cathy_> Bye now
18:00:36 <LouisF> bye
18:00:39 <s3wong> bye
18:00:48 <cathy_> #endmeeting