16:59:44 #startmeeting service_chaining 16:59:45 Meeting started Thu Nov 12 16:59:44 2015 UTC and is due to finish in 60 minutes. The chair is cathy_. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:59:46 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:59:48 The meeting name has been set to 'service_chaining' 16:59:53 o/ 16:59:54 hi everyone 16:59:55 hi 16:59:58 hi all 17:01:12 hope everyone had a good time at the summit. Now let's work on getting the sfc code ready and released. 17:01:55 I I have the following topics to discuss today 17:03:21 1. Flow classifier plugin being separate from port chain plugin, 2. Rebase our code on Neutron Liberty stable branch, 3. Dependency setup 4. Put Code review completion time line. 17:03:31 any other topic you would like to discuss? 17:04:05 #topic Flow classifier plugin being separate from port chain plugin 17:04:24 That looks like a good list, but if there's time I'd like to let people who aren't at OPNFV know about some of the conversations that took place yesterday. 17:04:47 pcarver: sure 17:04:55 hi 17:05:10 This separate FC plugin is a leftover topic from our last IRC meeting. 17:05:10 pcarver, good, thanks 17:05:55 It seems most of us think we should keep the FC plugin as a separate plugin from the port chain plugin. 17:06:04 Anyone has different opinion? 17:06:59 I think we should at least make a good faith effort to define a common classifier and only have a separate one if there are solid technical reasons why it can't be common. 17:07:38 There are at least three different components of Neutron that need to do flow classification and the user shouldn't be forced to use three different APIs. 17:08:11 Unless there's some really fundamental technical reason we can't express all the necessary semantics. 17:08:12 is it going to be extensible/supporting plugging in different classification criteria? say a custom L7 classification engine? 17:08:20 I agree. Aligning and working to define a common code base is in our best interest 17:08:34 pcarver: Agree. I think our current FC can be evolved easily to a common FC. 17:08:48 Sean Collins did some PoC work but I haven't had a chance to take a look at it. Did anybody else see it? 17:09:27 https://github.com/sc68cal/neutron-classifier 17:09:27 But for now, as we discussed before, let's keep it in networking-sfc but implement it as a separate plugin. 17:09:53 cathy_: agree on keeping it in until there's something ready to replace it with 17:09:54 as separate plugin for future migration 17:10:02 sorry, late 17:10:13 s3wong: hi 17:10:19 s3wong: np 17:10:19 cathy_ : Agree 17:11:59 igordcard: yes it will support L7 param based classification. But we have not implement that part yet, but the API has it 17:12:21 The API has an extension place for it. 17:13:33 cathy_, thanks, yeah I see the L7 params, have you finished the "design" of this? 17:13:39 So everyone agrees to keep the flow classifier in networking-sfc but implement it as a separate plugin? Any different opinion? 17:13:54 +1 17:13:57 +1 17:14:00 +1 17:14:01 +1 17:14:05 +1 17:14:11 igordcard: no detail design/implementation for this phase, we can do it in next phase 17:14:22 cathy_, okay, good, thanks 17:14:38 #agreed keep the flow classifier in networking-sfc but implement it as a separate plugin 17:14:45 now let's go to next topic 17:15:21 #topic Rebase our code on Neutron Liberty stable branch 17:16:36 I have not monitored the Liberty release label. Is there a stable label to rebase our sfc code? Or should we just base our code on master branch? 17:17:49 armax: are you there? Could you shed some light on this? 17:18:04 7.0.0 is the stable tag, but there is a stable/liberty branch as well 17:18:06 cathy_: I do believe it is customary for OpenStack release management to tag integrated release with stable/ 17:18:18 cathy_: for stable branches you should reach out to mestery 17:18:20 You probably want the branch if you want stable as critical fixes will be backported 17:18:28 mestery: he’s our release guru 17:18:34 armax cathy_: Even better, file a bug and follow the process :) 17:18:38 cathy_: do you need a stable branch? 17:19:16 armax: yes I would like to rebase SFC code on a stable Neutron branch 17:19:36 I don't think you want to cut a stable branch yet. 17:20:02 any particular reason for keeping it as a separate plugin ? 17:20:06 cathy_: ok 17:20:08 mestery: I think Cathy's question may be a bit different although I'm not sure I grasp the details. She's not asking about releasing networking-sfc, she's asking about pinning networking-sfc to a Neutron release 17:20:09 mestery: could you point us to a link on the filing bug and process? I know one link but would like to make sure it is the right one 17:20:30 pcarver: you are right 17:20:34 pcarver: Why would it be pinned to a neutron release? 17:20:37 That doesn't make sense 17:20:41 It's release independent 17:21:10 armax: What am I missing? 17:21:14 mestery: we have some dependency on neutron code 17:21:19 mestery: I'm not sure I understand the details, we may need more discussion on what exactly the dependency is 17:21:23 I'm not sure why you would want it pinned either 17:22:45 One issue we have (that we need to follow up on) is the subclassing of the OvS agent 17:23:07 pcarver: yes, that is the dependency. 17:23:39 We know we need to resolve that, but for the time being we're deriving a customized OvS agent from the Neutron one in order to add the OvS flows needed to direct traffic through chains 17:23:52 mestery: johnsom that is why I am thinking about rebasing to latest stable Neutron code base 17:24:44 so isn't it enough to make use of master neutron? 17:24:58 Wouldn't you want to track master changes? 17:25:24 I presume we're going to need to keep pulling OvS agent updates into networking-sfc until we can get an extensibility mechanism into the Neutron OvS agent that allows us to manipulate flows in the required manner 17:25:46 igordcard, johnsom: That's the ideal, but we don't think it works yet 17:26:02 igordcard: johnsom yes we would like to track master changes, but some times new bugs in master impact our testing 17:26:46 we need to to add flows into OvS and we don't think the Neutron OvS agent has a mechanism for us to extend it in the required way to add the flows we need 17:27:07 so I am thinking about doing sync once in a while to stable master branch labels. 17:27:31 pcarver, but neither does the liberty branch of it, right? 17:28:17 cathy_, sorry, sync to stable branches or master branch? 17:28:36 igordcard: correct. Discussion about enhancing the extensibility just came up at the summit and is still in the information gather stage. What we're talking about is the need to update networking-sfc's derived version periodically. 17:28:55 igordcard: sorry I was confusing you folks. 17:29:22 I am thinking about stable master branch labels. 17:29:30 Are there such labels? 17:30:26 pcarver, cathy_ , okay, yeah I see - so update it periodically so you get the best balance between mitaka-progress and not wasting time fixing conflicts due to recent master branch work in neutron 17:30:32 We don't want the networking-sfc derived agent to diverge from the upstream Neutron version in the mean time while we're working through what needs to be enhanced in the upstream version to allow us to deprecate the derived version. 17:30:35 Not that I am aware of. It's stable/liberty, master, or there will likely be lables for the milestones, M1, M2, etc 17:30:50 igordcard: yes 17:32:11 johnsom: Ok, then probably what we can do is to rebase to milestone labels? thought? 17:33:03 pcarver: yes, sure agree 17:34:42 johnsom: do you know if there us M1 label available now? 17:35:03 M1 gets cut the first week in December per the schedule 17:35:23 #link https://wiki.openstack.org/wiki/Mitaka_Release_Schedule 17:35:50 johnsom: thanks, then we can do the rebase in early December. 17:36:45 Ok, let's go to the next topic. 17:37:07 #topic dependency setup 17:38:11 Here is what is stated on the openstack guideline: The dependency on Neutron must not be present in requirements lists though, and instead belongs to tox.ini depenndency section. Direct library usage requires that this library is mentioned in requirements lists of the subproject To keep your subproject in sync with neutron, it is highly recommended that you register your project in openstack/requirements:projects.txt file t 17:39:07 Once a subproject opts in global requirements synchronization, it should enable check-requirements jobs in project-config. 17:40:39 could anyone take an action item to make sure our networking-sfc is doing what is stated above for subproject? 17:41:10 s3wong: pcarver could you help with this? 17:41:27 cathy_: I'll take a look at it 17:41:37 pcarver: thanks! 17:42:04 cathy_, the plan in the future is to merge back to neutron correct? 17:42:09 after mitaka 17:42:12 I understand the bit about the check-requirements job. I need to look into the bit about tox.ini part 17:42:31 pcarver You can look at neutron-lbaas which uses zuul cloner. Not sure if it's the right way to get neutron or not, but it works. 17:42:36 #action Paul will take a look at the dependency setup requirement for subproject and make sure our SFC is compliant with what is required. 17:43:57 igordcard: I don't think subproject needs to merge back to neutron. My understanding is that we can release independently but we need Neutron release team to help tag it for release. 17:44:26 Ok, let's go to next topic 17:44:53 #topic Put Code review completion time line 17:46:11 what is a good time line for everyone to finish the detail review for every patch out there and then we can start working on the release of the codes? 17:47:36 cathy_: some reviews have comments... should we wait for them to be addressed? 17:47:45 I am thinking about just putting one timeline. Each of us can work on the review of each patch based on our own schedule and expertise as long as we finish them by the time line. 17:48:02 s3wong: sure, we should upload new patches to incorporate those comments. 17:48:44 I just came back from business trip and then headed to the OPNVF Summit. I will take a look at all patches and make sure people upload new patches. 17:49:18 I will try to review as much as I can 17:49:27 I am thinking about having the comments incorporated by next Tuesday. 17:49:44 me and Prithiv want to further contribute to the design and development of networking-sfc 17:49:59 igordcard: thanks for joining the effort ! 17:50:10 cathy_: what kind of timeline are you thinking of? 17:50:13 cathy_: I'm backlogged with travel too, but am hoping to get some reviews done over the weekend (assuming I recover from being sick, I'm still not feeling great) 17:50:18 cathy_: by this month end we'll finish review and rework and start rebase by december 17:50:46 cathy_: I agree the patches had been under review for a while now; our original goal was to get them in before the summit, which didn't work out 17:51:08 mohankumar: I am OK with the time line your suggested 17:51:28 s3wong: yes, it is always postponed:-) let's be firm this time. 17:51:43 pcarver: thanks. Hope you will get better soon 17:51:52 cathy_:thanks 17:52:31 anyone disagree with end of Nov as the time line to finish and freeze the review as proposed by mohankumar ? 17:52:38 cathy_: so we are going with end of November then? 17:52:49 s3wong: ok with you? 17:52:50 cathy_: oops, we typed at the same time :-) 17:52:54 cathy_: +1 17:53:17 pcarver: johnsom igordcard ? 17:53:35 pcarver: johnsom igordcard OK with you? 17:53:36 +1 17:53:47 +1 17:53:50 Sure, that lines up with M1 nicely 17:54:40 #agreed we'll finish review and rework by end of Nov and start working on release in December 17:55:30 #topic update on OPNFV SFC presentation 17:55:53 pcarver: your turn:-) 17:56:06 we have 5 minutes left 17:56:14 4 min now:-) 17:56:19 So we had some interesting discussions at the OPNFV summit and there were quite a few presentations on SFC 17:56:42 One in particular involved Tacker invoking Open Daylight to perform the chaining. 17:57:03 that one bypasses Neutron 17:57:25 pcarver: yes, the Redhat folks want to put up a demo for the summit 17:57:35 Cathy and I were advocating for the use of networking-sfc as an API mediation layer which allows the implementation intelligence to reside in whatever SDN controller anyone happens to prefer 17:58:08 pcarver, cathy_: speaking as a Tacker team-member, we are fully onboard to use networking-sfc 17:58:21 After our presentation, people get to know the SFC work in neutron. The redhat guy is thinking about integrating tacker with networking-sfc 17:58:31 pcarver, cathy_: it is a work item for Tacker for the M release, around M-2 timeframe 17:58:42 s3wong: great. That is inline with my thought too 17:59:02 s3wong: great. I think it makes sense for Tacker to call networking-sfc API and then our driver model delegates out to whichever SDN controller mech driver is appropriate 17:59:41 cathy_: Dan and Tim are fully aware of networking-sfc, and we have agreed to use it --- however, we also need to have ODL driver for networking-sfc for their use case 17:59:53 I personally need to get up to speed with Tacker, but I tend to think that Tacker supporting different SFC APIs for all the myriad of SDN controllers is the wrong place 18:00:08 cathy_, pcarver: as you guys are fully aware, OPNFV seems to favor ODL 18:00:41 pcarver: no disagreement from me 18:00:45 hi 18:00:53 s3wong: I'm not sure that's 100% true. ODL was the only SDN controller in the first release of OPNFV, but now Contrail and ONOS seem to be showing a strong presence 18:01:08 LouisF: not aware of changes in PDT to PST? :-) 18:01:32 pcarver: I see. The OPNFV SFC team seems to be very committed to ODL though 18:01:34 s3wong: we need to let more people know Neutron's role and the SFC work. Otherwise people will think they can just integrate with ODL directly without using Neutron. 18:01:43 And I don't think that Tacker support for SFC should be dependent on OPNFV inclusion. 18:02:43 OK time is up. let's continue our discussion next week. 18:02:55 #endmeeting