16:59:44 <cathy_> #startmeeting service_chaining
16:59:45 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:59:48 <openstack> The meeting name has been set to 'service_chaining'
16:59:53 <johnsom> o/
16:59:54 <cathy_> hi everyone
16:59:55 <pcarver> hi
16:59:58 <igordcard> hi all
17:01:12 <cathy_> hope everyone  had a good time at the summit. Now let's work on getting the sfc code ready and released.
17:01:55 <cathy_> I I have the following topics to discuss today
17:03:21 <cathy_> 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 <cathy_> any other topic you would like to discuss?
17:04:05 <cathy_> #topic Flow classifier plugin being separate from port chain plugin
17:04:24 <pcarver> 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 <cathy_> pcarver: sure
17:04:55 <mohankumar> hi
17:05:10 <cathy_> This separate FC plugin is a leftover topic from our last IRC meeting.
17:05:10 <igordcard> pcarver, good, thanks
17:05:55 <cathy_> It seems most of us think we should keep the FC plugin as a separate plugin from the port chain plugin.
17:06:04 <cathy_> Anyone has different opinion?
17:06:59 <pcarver> 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 <pcarver> 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 <pcarver> Unless there's some really fundamental technical reason we can't express all the necessary semantics.
17:08:12 <igordcard> is it going to be extensible/supporting plugging in different classification criteria? say a custom L7 classification engine?
17:08:20 <johnsom> I agree.  Aligning and working to define a common code base is in our best interest
17:08:34 <cathy_> pcarver: Agree. I think our current FC can be evolved easily to a common FC.
17:08:48 <pcarver> 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 <pcarver> https://github.com/sc68cal/neutron-classifier
17:09:27 <cathy_> But for now, as we discussed before, let's keep it in networking-sfc but implement it as a separate plugin.
17:09:53 <pcarver> cathy_: agree on keeping it in until there's something ready to replace it with
17:09:54 <cathy_> as separate plugin for future migration
17:10:02 <s3wong> sorry, late
17:10:13 <cathy_> s3wong: hi
17:10:19 <cathy_> s3wong: np
17:10:19 <mohankumar> cathy_ :  Agree
17:11:59 <cathy_> 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 <cathy_> The API has an extension place for it.
17:13:33 <igordcard> cathy_, thanks, yeah I see the L7 params, have you finished the "design" of this?
17:13:39 <cathy_> So everyone agrees to keep the flow classifier in networking-sfc but implement it as a separate plugin? Any different opinion?
17:13:54 <pcarver> +1
17:13:57 <johnsom> +1
17:14:00 <igordcard> +1
17:14:01 <s3wong> +1
17:14:05 <mohankumar> +1
17:14:11 <cathy_> igordcard: no detail design/implementation for this phase, we can do it in next phase
17:14:22 <igordcard> cathy_, okay, good, thanks
17:14:38 <cathy_> #agreed keep the flow classifier in networking-sfc but implement it as a separate plugin
17:14:45 <cathy_> now let's go to next topic
17:15:21 <cathy_> #topic Rebase our code on Neutron Liberty stable branch
17:16:36 <cathy_> 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 <cathy_> armax: are you there? Could you shed some light on this?
17:18:04 <johnsom> 7.0.0 is the stable tag, but there is a stable/liberty branch as well
17:18:06 <s3wong> cathy_: I do believe it is customary for OpenStack release management to tag integrated release with stable/<release-name>
17:18:18 <armax> cathy_: for stable branches you should reach out to mestery
17:18:20 <johnsom> You probably want the branch if you want stable as critical fixes will be backported
17:18:28 <armax> mestery: he’s our release guru
17:18:34 <mestery> armax cathy_: Even better, file a bug and follow the process :)
17:18:38 <armax> cathy_: do you need a stable branch?
17:19:16 <cathy_> armax: yes I would like to rebase SFC code on a stable Neutron branch
17:19:36 <johnsom> I don't think you want to cut a stable branch yet.
17:20:02 <Prithiv> any particular reason for keeping it as a separate plugin ?
17:20:06 <armax> cathy_: ok
17:20:08 <pcarver> 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 <cathy_> 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 <cathy_> pcarver: you are right
17:20:34 <mestery> pcarver: Why would it be pinned to a neutron release?
17:20:37 <mestery> That doesn't make sense
17:20:41 <mestery> It's release independent
17:21:10 <mestery> armax: What am I missing?
17:21:14 <cathy_> mestery: we have some dependency on neutron code
17:21:19 <pcarver> mestery: I'm not sure I understand the details, we may need more discussion on what exactly the dependency is
17:21:23 <johnsom> I'm not sure why you would want it pinned either
17:22:45 <pcarver> One issue we have (that we need to follow up on) is the subclassing of the OvS agent
17:23:07 <cathy_> pcarver: yes, that is the dependency.
17:23:39 <pcarver> 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 <cathy_> mestery: johnsom that is why I am thinking about rebasing to latest stable Neutron code base
17:24:44 <igordcard> so isn't it enough to make use of master neutron?
17:24:58 <johnsom> Wouldn't you want to track master changes?
17:25:24 <pcarver> 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 <pcarver> igordcard, johnsom: That's the ideal, but we don't think it works yet
17:26:02 <cathy_> igordcard: johnsom yes we would like to track master changes, but some times new bugs in master impact our testing
17:26:46 <pcarver> 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 <cathy_> so I am thinking about doing sync once in a while to stable master branch labels.
17:27:31 <igordcard> pcarver, but neither does the liberty branch of it, right?
17:28:17 <igordcard> cathy_, sorry, sync to stable branches or master branch?
17:28:36 <pcarver> 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 <cathy_> igordcard: sorry I was confusing you folks.
17:29:22 <cathy_> I am thinking about stable master branch labels.
17:29:30 <cathy_> Are there such labels?
17:30:26 <igordcard> 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 <pcarver> 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 <johnsom> 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 <cathy_> igordcard: yes
17:32:11 <cathy_> johnsom: Ok, then probably what we can do is to rebase to milestone labels? thought?
17:33:03 <cathy_> pcarver: yes, sure agree
17:34:42 <cathy_> johnsom: do you know if there us M1 label available now?
17:35:03 <johnsom> M1 gets cut the first week in December per the schedule
17:35:23 <johnsom> #link https://wiki.openstack.org/wiki/Mitaka_Release_Schedule
17:35:50 <cathy_> johnsom: thanks, then we can do the rebase in early December.
17:36:45 <cathy_> Ok, let's go to the next topic.
17:37:07 <cathy_> #topic dependency setup
17:38:11 <cathy_> 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 <cathy_> Once a subproject opts in global requirements synchronization, it should enable check-requirements jobs in project-config.
17:40:39 <cathy_> could anyone take an action item to make sure our networking-sfc is doing what is stated above for subproject?
17:41:10 <cathy_> s3wong: pcarver  could you help with this?
17:41:27 <pcarver> cathy_: I'll take a look at it
17:41:37 <cathy_> pcarver: thanks!
17:42:04 <igordcard> cathy_, the plan in the future is to merge back to neutron correct?
17:42:09 <igordcard> after mitaka
17:42:12 <pcarver> I understand the bit about the check-requirements job. I need to look into the bit about tox.ini part
17:42:31 <johnsom> 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 <cathy_> #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 <cathy_> 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 <cathy_> Ok, let's go to next topic
17:44:53 <cathy_> #topic Put Code review completion time line
17:46:11 <cathy_> 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 <s3wong> cathy_: some reviews have comments... should we wait for them to be addressed?
17:47:45 <cathy_> 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 <cathy_> s3wong: sure, we should upload new patches to incorporate those comments.
17:48:44 <cathy_> 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 <igordcard> I will try to review as much as I can
17:49:27 <cathy_> I am thinking about having the comments incorporated by next Tuesday.
17:49:44 <igordcard> me and Prithiv want to further contribute to the design and development of networking-sfc
17:49:59 <cathy_> igordcard: thanks for joining the effort !
17:50:10 <s3wong> cathy_: what kind of timeline are you thinking of?
17:50:13 <pcarver> 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 <mohankumar> cathy_:  by this month end we'll  finish review and rework and start rebase by december
17:50:46 <s3wong> 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 <cathy_> mohankumar: I am OK with the time line your suggested
17:51:28 <cathy_> s3wong: yes, it is always postponed:-) let's be firm this time.
17:51:43 <cathy_> pcarver: thanks. Hope you will get better soon
17:51:52 <mohankumar> cathy_:thanks
17:52:31 <cathy_> anyone disagree with end of Nov as the time line to finish and freeze the review as proposed by mohankumar ?
17:52:38 <s3wong> cathy_: so we are going with end of November then?
17:52:49 <cathy_> s3wong: ok with you?
17:52:50 <s3wong> cathy_: oops, we typed at the same time :-)
17:52:54 <s3wong> cathy_: +1
17:53:17 <cathy_> pcarver: johnsom igordcard ?
17:53:35 <cathy_> pcarver: johnsom igordcard OK with you?
17:53:36 <igordcard> +1
17:53:47 <pcarver> +1
17:53:50 <johnsom> Sure, that lines up with M1 nicely
17:54:40 <cathy_> #agreed we'll  finish review and rework by end of Nov and start working on release in December
17:55:30 <cathy_> #topic update on OPNFV SFC presentation
17:55:53 <cathy_> pcarver: your turn:-)
17:56:06 <cathy_> we have 5 minutes left
17:56:14 <cathy_> 4 min now:-)
17:56:19 <pcarver> So we had some interesting discussions at the OPNFV summit and there were quite a few presentations on SFC
17:56:42 <pcarver> One in particular involved Tacker invoking Open Daylight to perform the chaining.
17:57:03 <cathy_> that one bypasses Neutron
17:57:25 <s3wong> pcarver: yes, the Redhat folks want to put up a demo for the summit
17:57:35 <pcarver> 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 <s3wong> pcarver, cathy_: speaking as a Tacker team-member, we are fully onboard to use networking-sfc
17:58:21 <cathy_> 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 <s3wong> pcarver, cathy_: it is a work item for Tacker for the M release, around M-2 timeframe
17:58:42 <cathy_> s3wong: great. That is inline with my thought too
17:59:02 <pcarver> 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 <s3wong> 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 <pcarver> 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 <s3wong> cathy_, pcarver: as you guys are fully aware, OPNFV seems to favor ODL
18:00:41 <s3wong> pcarver: no disagreement from me
18:00:45 <LouisF> hi
18:00:53 <pcarver> 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 <s3wong> LouisF: not aware of changes in PDT to PST?  :-)
18:01:32 <s3wong> pcarver: I see. The OPNFV SFC team seems to be very committed to ODL though
18:01:34 <cathy_> 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 <pcarver> And I don't think that Tacker support for SFC should be dependent on OPNFV inclusion.
18:02:43 <cathy_> OK time is up. let's continue our discussion next week.
18:02:55 <cathy_> #endmeeting