17:01:23 #startmeeting SFC project 17:01:23 Meeting started Thu Jun 11 17:01:23 2015 UTC and is due to finish in 60 minutes. The chair is cathy_. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:01:24 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:01:26 The meeting name has been set to 'sfc_project' 17:01:29 o/ 17:01:32 hi everyone 17:01:34 Hi Cathy, This is Ramanjaneya..from vikram team 17:01:35 hi 17:01:39 cathy_: hello 17:01:43 hi all 17:01:53 hi Ramanjaneya 17:02:01 ok let's start 17:02:41 #topic update on action items of last meeting 17:03:16 So the repository for this feature development is being created. 17:03:21 hi 17:03:38 armax: are you there? 17:03:45 Swami: hi 17:03:52 hi 17:03:55 hello 17:04:43 For the network controller driver, I have updated the slide for that 17:04:52 nbouthors: hi 17:05:18 armax: do you have if the repository has been created or the infra team is still reviewing it? 17:05:32 I means do you know? 17:05:48 cathy_: it’s still in progress…I suspect the infra team is busy dealing with a few project renames 17:05:59 cathy_: it’ll be a little while longer 17:06:06 armax: ok, thanks 17:07:17 here is the link to the slides https://docs.google.com/presentation/d/1SpVyLBCMRFBpMh7BsHmpENbSY6qh1s5NRsAS68ykd_0/edit?usp=sharing 17:07:35 any comment or questions on the action items? 17:08:10 cathy_: let me reply to your question regarding agentless architecture in this forum 17:08:18 Ok, let's go to the next topic 17:08:29 ? 17:08:38 #topic Neutron port chain API 17:09:08 armax: go ahead 17:09:18 cathy_: can you post your question here for the benefit of the audience. 17:09:57 . 17:10:01 armax: go ahead 17:10:25 cathy_: ok 17:10:40 I am assuming that in slide 2 17:11:20 that the component running the ovs agent is compute host? 17:11:25 or can it be something else? 17:11:41 armax: Yes it is the compute host. 17:11:54 armax: yes 17:12:01 armax: yes 17:12:10 having said that, I was asking if you guys had considered making the interaction between the controller node and the compute node without relying on the ovs agent 17:12:22 Both traffic classifier and SFF? 17:12:38 what do you mean by the controller node? 17:12:53 controller node is the neutron server node. 17:12:55 armax: can you give more details and perhaps and exmaple of where this is done? 17:13:02 an example 17:13:29 anyhow some for thought, I think it’s premature to talk about the architecture if we don’t first finalize whe most rudimentary API we want to implement this cycle 17:13:54 LouisF: well, we don’t necessily need to talk to the ovs agent, that’s all 17:14:28 LouisF: for example in the current OVN architecture there is no agent in the compute node. So in future if we want to adopt such technology, we should be able to go agentless. That is what armax is pointing out. 17:14:59 In existing OVS, it talks to the neutron Server through OVS agent. Are you suggesting to change this? 17:15:09 all I am saying is that OVS can be controlled remotely 17:15:26 just like other solutions do 17:16:19 cathy_: I am simply asking if you had considered it 17:16:26 cathy_: I am not suggesting anything right now :) 17:16:54 sonds like that is worthwile considering 17:17:02 armax: it is a possible option in the future 17:17:35 cathy_: I wouldn’t rule it out completely, and consider it a ‘future’ option 17:18:03 Will the OVN architecture available in L release? 17:18:31 cathy_: because until we figure out what interaction is required with the vswitch everything is fair game 17:18:41 cathy_: OVN has nothing to do with what I am saying 17:19:24 I see that Swami said that you are referring to OVN architecture. 17:19:44 cathy_: I just gave an example for LouisF. 17:19:59 Swami: no I wasn't 17:20:48 Maybe it is better to discuss this in the email to clarify what you have in mind. Let's move on to next topic 17:21:03 armax: OK with you? 17:21:38 cathy_: yss 17:21:47 cathy_: other examples would be Contrail and Nuage. Nothing specific to OVN, just lots of options out there that either do or will support service chaining 17:22:12 The service chaining API shouldn't be tied tightly to any one implementation 17:22:33 pcarver: noone is saying otherwise as far as I can tell :) 17:22:46 pcarver: agree, there should drivers for a wide variety of backend implementations 17:22:52 So if you are talking about different types of SDN controller, then it is through controller driver which is separate from the OVS driver. how about we discuss this in the email since the meeting time is short. 17:22:52 should be 17:23:07 $topic Neutron port chain API for SFC 17:23:19 #topic 2. Neutron port chain API for SFC 17:23:36 cathy_: I recall that vikram was going to respin https://review.openstack.org/#/c/177946 17:23:43 cathy_: any news on that? I have seen nothing popping up 17:24:03 is vikram around? 17:24:09 HI cathy .. 17:24:17 mohan here from vikram team 17:24:19 armax: i will be updating, vikram is on vavation 17:24:23 vacation 17:24:28 armax: vikram is on vacation. Louis will take care of this 17:24:43 we started neutron client changes 17:24:45 LouisF: ok, thanks, I think ultimately that spec will have to be moved over to the repo for SFC once we have it up and running 17:25:01 armax: yes thanks 17:25:01 LouisF: but for now, let’s iterate on that patch 17:25:09 armax: agree 17:25:17 We will update the spec incorporating all the comments/input 17:25:39 Hi I'm Ramanjaneya from vikram team.. 17:25:40 on behalf of vikram, Mohan started neutron client changes.. 17:26:26 let's now discuss the API and see if any questions/comments? 17:26:55 qwebirc1003062: the neutron client changes are the last thing you wan’t to do 17:27:03 *want 17:27:35 I know quite some people have given comments on that spec. Any issue/input that we can discuss in this meeting? 17:28:10 To move forward and make it for the L release, we need to reach consensus on the API and finalize the API 17:28:11 we need to get conensus and agreement on the api first before making any changes 17:28:48 agree 17:28:59 maybe we should put a time line on finalizing the API 17:29:06 ? 17:29:11 cathy_: reviewing the API in the current status of the spec is a bit painful 17:29:21 cathy_: as the wrong diff gets in the way 17:29:49 this might deter some people from reviewing perhaps? 17:30:00 armax: what do you mean by that? 17:30:18 armax: what do you mean by wrong diff? 17:30:18 LouisF: https://review.openstack.org/#/c/177946/ 17:30:38 it shows that patch 177946 depends on an abandoned patch 17:30:48 and the actual diff includes two modified files and a deleted one 17:30:59 for something that should be freshly proposed that hardly makes any sense 17:31:18 the diff is: +124, -510 17:31:25 when it should simply be only additions 17:31:28 armax: yes, that is a confusing. Louis could you fix that? 17:31:32 armax: ok 17:33:23 so Louis will clean that up. Quite come people have given comments and there are multiple updated versions. I would suggest that everyone goes to the link and check the latest version and see if you have any more comments. 17:34:37 cathy_: yes, I’d give us one more week to see if we can pull it together 17:34:45 How about we get the review completed in two weeks from today so that we can start developing the code? 17:35:01 armax: one week is OK with me 17:35:05 cathy_: once the repo is set up and we move the spec over there, we can have one final push and start iterating on the code itself 17:35:39 armax: i will put the spec in the networking-sfc repo 17:36:15 cathy_: do we know of anyone who has started coding on a skeleton of the architecture that you put together with Sw? 17:36:20 *Swami 17:36:31 armax:hi 17:36:32 armax: Ok, so let's get the review done in one week and then we will have the spec over the new repo and start implementing it 17:37:32 some people have contacted me to sign up for development of different pieces of the architecture, We will cover this later in this meeting. 17:37:43 cathy_: cool 17:37:51 that is one of our meeting topics too 17:38:07 now let's go to next topic 17:38:34 #topic Unified API and data model for flow classifier that can be used for SFC, QoS, Packet forwarding etc. 17:39:50 Since Yujin can not join this IRC meeting and Vikram has signed up on driving this and Vikram is on vacation. let's move this topic to next meeting. 17:40:17 cathy_: Here is the link to the spec. #link https://review.openstack.org/#/c/186663/ 17:40:24 So let's go to next topic 17:40:38 cathy_: although I am in favor of this initiative, I am not sure it’s the most sensible thing to do right now 17:41:21 cathy_: I wonder if it’s better striving for some unification once we got some practical experience on how all these initiatives play out 17:41:24 Swami: the flow classifier in https://review.openstack.org/#/c/186663/ is very similar to the flow classifier proposed in https://review.openstack.org/#/c/177946/ 17:41:38 armax: is would be useful to have a common api for a flow classifier 17:41:50 armax: agree 17:42:23 cathy_: especially if these initiatives are tacked separately, it may be difficult to coordinate who does what 17:42:27 LouisF: agree 17:43:07 Since what Yujin proposed and wanted for packet forwarding is very close to what is proposed by the SFC spec https://review.openstack.org/#/c/177946/, let's implement the flow classifier in this SFC project but make it a independent module which cna be used or extended for other use case 17:44:05 cathy_: have you communicated to Yujin on this. 17:44:20 Agree with Armax that let's first play it out and get some practical experience. 17:44:25 Swami: I will via email 17:45:16 Swami: it will be confusing to propose very similar API and data model in two separate spec. Let's merge it into one spec 17:45:41 cathy_: agree 17:45:58 Shall we move to the next topic? 17:45:59 lets suggest that to Yuji 17:46:12 LouisF: yes 17:46:43 #topic : functional module breakdown and Module development ownership sign-up 17:47:06 let's reference to the slide and I will go one by one 17:47:17 slide 4 17:48:04 1. repo creation, Armax has taken this. Thanks Armax! 17:48:26 2 Integration with Neutron/devstack, CLI, Horizon, Heat, Anyone wants to take this? 17:49:33 Mohankumar_: would you like to take this work? 17:50:02 yes cathy 17:50:17 great, Thanks Mohankumar_ ! 17:50:47 now Service chain API Extension. Anyone takes this? 17:50:49 i can take that 17:50:57 Thanks Louis! 17:51:11 thanks :) 17:51:19 Service chain Plugin: API handling and Data Base. Anyone? 17:51:42 i'l do that also 17:51:48 I can take this 17:51:56 Thanks Louis! 17:52:44 OVS Driver ? 17:52:53 we need to also have a driver manager 17:53:20 LouisF: do you mean the common service chain API shim layer? 17:53:24 to handle the different backend drivers eg ovs, odl.... 17:53:31 yes 17:53:51 common service chain API shim layer. Anyone wants to take this piece? 17:54:14 i will look at that 17:54:25 ok, thanks louis! 17:54:49 OVS agent on Host. Anyone taking this piece? 17:54:52 cathy_: it’s probably better to ask what LouisF doesn’t want to do :) 17:55:03 armax: :-) 17:55:06 cathy_: for that I’d wait a little longer, as we might not even need it 17:55:27 please volunterer and i am glad to hand off 17:55:40 you mean use ovn? 17:55:40 armax: OK, let's go to the next piece 17:55:45 this task assigment is going to be in flux anyway…in my experience people come and go so we’d need to be prepared to step in :) 17:55:51 LouisF: forget about OVN :) 17:56:11 LouisF: I never mentioned it and blame Swami for putting it in people’s mind 17:56:12 s 17:56:18 LouisF: If you want me to take up the ext and plugin part I can take it. 17:56:23 :] 17:56:27 armax: 100% agree with that we need to be prepared to step in. 17:56:44 armax: I swear that I just gave an example 17:56:53 Service chain Classifier on host. Anyone? 17:57:23 Swami: I know, I know :) 17:57:31 Hi! anyone tried to run CI on top of Fuel Juno using ESX? 17:57:33 may nicolas? 17:57:36 maybe 17:57:37 I know that Nicolos will take this piece. He has told me that 17:58:13 Service function forwarder with NSH Type 2 encapsulation. Anyone? 17:58:31 Swami: would you like to take this? 17:58:54 I can help with this piece too 17:59:30 Swami: ? 17:59:50 cathy_: sorry I was looking at some other information. 17:59:50 What are you going to use as NSH-aware VNFs? 17:59:51 cathy: we can provide a service classifier 17:59:57 cathy_: yes i am here 18:00:12 cathy_: I can help with the classifier. 18:00:51 igordcard: not NSH-aware VNF for the first release 18:01:02 let's wrap the meeting up. 18:01:11 and continue in next meeting. 18:01:17 Thanks everyone. Bye now 18:01:30 bye 18:01:35 bye 18:01:45 bye ! 18:01:48 #endmeeting