17:00:56 <cathy_> #startmeeting service_chaining
17:00:56 <openstack> Meeting started Thu Nov 19 17:00:56 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:58 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:01:01 <openstack> The meeting name has been set to 'service_chaining'
17:01:05 <cathy_> hi everyone
17:01:09 <igordcard> hi cathy_
17:01:14 <mohankumar> hi cathy_
17:01:39 <ramanjaneya_> Hi
17:02:38 <johnsom> o/
17:02:42 <LouisF> hi
17:03:00 <cathy_> OK, let's start
17:03:34 <s3wong> hello
17:03:59 <cathy_> I put the topics in the meeting wiki, I will start from the first one
17:04:17 <cathy_> #topic Follow-up on previous meeting discussion: Tacker to call networking-sfc API and then our driver model delegates out to whichever SDN controller mech driver is appropriate
17:05:44 <cathy_> s3wong: This is what we discussed in last meeting. Since you are working on Tacker, is this in sync with what Tacker team is thinking about?
17:06:09 <KLuehrs> Hi - new to Tacker. Is there a web conference/teleconference bridge for this meeting? I didn't see one on the /Meetings/Tacker wiki page
17:06:16 <s3wong> cathy_: I asked Tacker PTL to join today's meeting also --- sridhar_ram?
17:06:50 <igordcard> KLuehrs, text only
17:06:52 <s3wong> KLuehrs: our weekly meeting is on Tuesday, 1700 UTC on #openstack-meeting-4
17:07:12 <sridhar_ram> hi folks .. I'm here
17:07:13 <KLuehrs> OK thanks.
17:08:03 <s3wong> cathy_: so I spoke with sridhar_ram on #tacker channel regarding the ODL direct integration
17:08:12 <s3wong> (and sridhar_ram is here now)
17:08:26 <s3wong> sridhar_ram: you want to take it from here?
17:08:32 <sridhar_ram> s3wong: sure...
17:08:54 <sridhar_ram> cathy_: and team .. our plan is always use networking-sfc as the preferred option
17:09:18 <sridhar_ram> we also understand it will take sometime as we are all building things in parallel..
17:09:50 <sridhar_ram> tacker user community has been asking to try out SFC use-cases for a while ..
17:10:01 <cathy_> sridhar_ram: OK, great. thanks for the info. Sure it will take time and we will work with you on that.
17:10:02 <sridhar_ram> .. and now we have an option by using ODL
17:10:46 <sridhar_ram> cathy_: here is a slides I shared w/ OPNFV-SFC team sometime back .. https://docs.google.com/presentation/d/18AGaiysVgHOd_fIHVpObMO7zUkMjJGOQ98CUwkxU1xo/edit#slide=id.p14
17:11:13 <sridhar_ram> cathy_: I showed a multi phase approach .. we are in phase 1 (slide 5)
17:11:33 <sridhar_ram> plan is to eventually move to phase 3 (slide 7)
17:12:01 <cathy_> sridhar_ram: OK, we will take a look at the slides after the meeting.
17:12:04 <pcarver_> hi. I joined late.
17:12:12 <cathy_> pcarver_: hi
17:12:15 <LouisF> sridhar_ram: slide 8 shows a odl driver - are there plans to add a networking-sfc driver?
17:12:41 <LouisF> does tacker support the ability to add other drivers?
17:12:50 <sridhar_ram> LouisF: In fact, that was my understanding ... I was about to ask the same to this team here :)
17:13:46 <LouisF> i think iut would be useful to add a driver manager to tacker to support various SB drivers
17:13:56 <cathy_> sridhar_ram: slide 7 is in sync with our discussion in last meeting. Great that tacker will move to phase 3 slide 7.
17:14:20 <s3wong> LouisF: I don't think Tacker is in the business of integrating with SB SDN / network drivers long term
17:14:37 <cathy_> agree with s3wong
17:14:47 <s3wong> LouisF: once networking-sfc stabilizes, networking-sfc would likely be the only thing we will be using moving forward
17:15:02 <s3wong> which is the phase 3 diagram in sridhar_ram 's slides
17:15:58 <cathy_> OK, let's move to second topic
17:16:02 <LouisF> s3wong: slide 8 shows a sfc driver
17:16:02 <s3wong> hopefully by the next OPNFV summit, we will have a fully integrated solution :-)
17:16:42 <sridhar_ram> LouisF: tacker can have multiple SFC drivers backing its sfc-extension API
17:17:04 <sridhar_ram> LouisF: but our preference is to go through networking-sfc API as much as possible
17:17:07 <igordcard> it's interesting... tacker team, do you intend to leverage most of the opendaylight-sfc features through networking-sfc (in the case of an ODL networking-sfc driver)?
17:17:18 <igordcard> including SFC encapsulation
17:17:38 <s3wong> igordcard: encapsulation (and anything plumbing related) --- definitely
17:17:47 <sridhar_ram> LouisF: .. along the lines we are taking a practical approach to enable SFC in tacker
17:17:55 <LouisF> sridhar_ram: great i think networking-sfc would be very interested in working with tacker team on a tacker - networking-sfc driver
17:18:11 <sridhar_ram> LouisF: thanks!
17:18:26 <s3wong> igordcard: but my understanding (which admittedly is a bit limited) is that ODL SFC also has a chain template portion, which Tacker may need to service
17:18:35 <sridhar_ram> igordcard: we need reconcile the features of odl-sfc and the networking-sfc api ..
17:18:41 <igordcard> s3wong, that's good, we need to make sure networking-sfc is abstract or flexible enough to allow that, somehow, through their API
17:18:50 <sridhar_ram> igordcard: +1
17:18:53 <s3wong> igordcard: as this template stuff affects lifecycle management of the service VMs
17:19:18 <sridhar_ram> I've one question to the team here..
17:19:22 <s3wong> igordcard: agreed
17:19:38 <sridhar_ram> have you looked at ODL-SFC for ideas to expand the proposed networking-sfc api ?
17:20:07 <sridhar_ram> the reason I ask.. it seems one of the good opensource NSH-OVS enabled SFC out there ?
17:20:27 <s3wong> sridhar_ram: (now speaking as a member of the networking-sfc team) I believe the SFP portion of the APIs can be well serviced by networking-sfc with minimal changes
17:20:57 <LouisF> s3wong: agree
17:21:07 <s3wong> sridhar_ram: for the NSH problem --- unfortunately unlike ODL, us in Neutron need to adhere to what is available as standard (OVS releases)
17:21:20 <sridhar_ram> s3wong: my high level thought pt is .. we should degrade ODL's SFC capability "too much" if consumed through networking-sfc
17:21:31 <sridhar_ram> s/should/SHOULD NOT/
17:21:51 <cathy_> sridhar_ram: Could you be more specific? which one do you think networking-sfc api does not satisfy?
17:22:04 <s3wong> sridhar_ram: so we are all eagerly waiting for OVS to have NSH support... it is promising, as folks from Intel is currently pushing for this effort, and that Jesse Gross seems to be working with the folks at Intel to get the support in
17:22:11 <cathy_> sridhar_ram: the API allows specification of encap mechanism including NSH
17:22:46 <igordcard> s3wong, sure, so should the framework be able support the different capabilities depending on the active driver? while still having a stable API
17:22:51 <sridhar_ram> cathy_: that's good to hear encap is allowed .. we might also need transport_type (that is up for discussion thougth)
17:22:56 <cathy_> as s3wong said, when NSH is officially accepted by OVS, we can easily incorporate it in.
17:23:04 <s3wong> sridhar_ram: that said, once we have networking-sfc driver for ODL SFC, the ODL SFC code is standard release (Lithium), and we would be able to use whatever OVS fork ODL decides to use :-)
17:23:06 <sridhar_ram> cathy_: more info is available in tacker-sfc spec .. https://review.openstack.org/#/c/228007/3/specs/liberty/tacker-sfc.rst
17:23:22 <LouisF> sridhar_ram: when nsh is available in a released ovs version networking-sfc can take advantage if it
17:23:51 <cathy_> Our API allows more flexibility than just restricting to one encap mechanism and the flexibility is the feedback we got at our design stage
17:24:01 <s3wong> sridhar_ram: I do believe ODL SFC integration would likely push us (networking-sfc team) to expand on the params field of the port chain to include NSH and related parameters
17:24:02 <sridhar_ram> LouisF: sounds good...my understanding is that is getting close..
17:24:11 <sridhar_ram> s3wong: that's promising!
17:24:57 <pcarver_> We may need to think about adding some sort of capability discovery to the API
17:25:10 <igordcard> s3wong, glad to hear that.. and that pcarver_
17:25:18 <s3wong> sridhar_ram, LouisF, cathy_: I do believe (as I mentioned above), with the ODL SFC driver (in networking-sfc), we can have NSH, since technically the ODL SFC support is an official OSS project release (sidestep the fact that THEY are using a fork version of OVS :-)  )
17:25:48 <s3wong> pcarver_: that's an interesting thought...
17:26:07 <sridhar_ram> s3wong: pcarver_: as long as we have a n-sfc api that is a rough superset .... we would be good
17:26:29 <s3wong> sridhar_ram: certainly
17:26:40 <cathy_> s3wong: yes, with ODL SFC driver in networking-sfc, we can have NSH. Or even without the ODL driver, we can have it through OVS driver directly
17:27:36 <LouisF> cathy_: that would work
17:28:21 <s3wong> cathy_, sridhar_ram: glad we have an agreement on the integration plan. Good discussion!
17:28:48 <cathy_> LouisF: s3wong sure:-)
17:28:53 <cathy_> pcarver_: for the capability discovery addition to the API, we can discuss after we get the first phase functionality and codes merged. OK with you?
17:29:11 <LouisF> sridhar_ram: i think it would be useful to add a slide to your deck that outlines what we are proposing here
17:29:22 <pcarver_> cathy_: absolutely. We need to cover the common SFC functionality of major SDN controllers first
17:30:00 <LouisF> pcarver_: +1
17:30:04 <pcarver_> It's just that if we find that some SDN controllers have capabilities that others don't, we don't want networking-sfc to restrict the capabilities
17:30:15 <cathy_> pcarver_: sure, agree
17:30:22 <pcarver_> but we don't want end users to have to guess at what's supported either
17:30:27 <igordcard> cathy_, assuming the API/framework and so on are still open for changes after the first phase gets merged, I'm completely +1 with you - it will also be easier to just check out the code, stack it and try it
17:30:53 <LouisF> igordcard: +1
17:31:27 <s3wong> cathy_: time for next topic?
17:31:32 <s3wong> :-)
17:31:34 <igordcard> pcarver_, +1
17:31:53 <cathy_> igordcard: sure it will be open for changes/extensions. We need to define more extensions to support richer functionality and more scenarios. I have all those in mind, but let's do step by step:-)
17:32:01 <sridhar_ram> LouisF: sure. I can add one..
17:32:04 <cathy_> s3wong: sure let's go to next topic
17:32:09 <igordcard> cathy_, perfect
17:32:20 <sridhar_ram> LouisF: we can maintain this as a common set of slides for our common user community
17:32:23 <pcarver_> igordcard: we just added a warning to the docs that the API is experimental and subject to change
17:32:42 <cathy_> #topic Patch update progress
17:32:45 <sridhar_ram> pcarver_: +1 ..
17:35:14 <cathy_> So we have spent quite some time doing rebase and solving those build errors due to dependency order. Now we have re-split the FC plugin from the port chain plugin per our agreement last time.
17:35:44 <pcarver_> who has all of the code installed and running? I keep running into problems.
17:36:30 <cathy_> pcarver_: we once had all codes installed and running.
17:36:32 <pcarver_> It would be helpful if someone who has it working could replicate setup from a fresh new DevStack and write down all the steps in the correct order.
17:37:46 <igordcard> pcarver_, +2
17:38:18 <cathy_> but due to some name changes in FC and other config changes (Vikram made if I am right), we are having some problems. We have been working on fixing those and uploading patches
17:39:13 <cathy_> pcarver_: What we did is manual installation, not via devstack.
17:39:20 <igordcard> I have very recently finished a rebase on this even though I'm not sure if FC is working, I can share the git repo if you want to test it... q-svc runs
17:39:24 <pcarver_> We also need to verify whether the tox config is correct. There are a lot of failures in the gate. I don't know if those are gate problems or code problems.
17:39:45 <pcarver_> cathy_: What base OpenStack are you using?
17:40:16 <cathy_> pcarver_: yes, we are working on those problems. If you look at the latest update, most failures are fixed.
17:40:16 <LouisF> pcarver_: the tox gate failures have been resolved
17:40:42 <cathy_> pcarver_: what do you mean by base openstack?
17:40:57 <cathy_> we are based on Liberty
17:41:01 <LouisF> pcarver_: will post latest ovs driver changes
17:41:12 <pcarver_> cathy_: Did you mean you're not using DevStack? Or just that you didn't use DevStack to install networking-sfc
17:41:29 <cathy_> pcarver_: did not use devstack
17:41:32 <igordcard> LouisF, thanks
17:41:42 <cathy_> pcarver_: not yet
17:41:44 <pcarver_> cathy_: I mean are you using Fuel or RDO or a fully manual installation of OpenStack?
17:41:56 <cathy_> pcarver_: manual
17:42:26 <pcarver_> cathy_: So everything, Nova, Glance, Keystone all manually installed and configured without automation?
17:42:39 <cathy_> pcarver_: if you talk about basic openstack, then it is not manual
17:43:07 <pcarver_> cathy_: That's what I'm asking about. What are you using to setup the OpenStack that you're manually adding networking-sfc to
17:43:54 <cathy_> pcarver_ it is through devstack. But we also run into some problems which we have to debug and manually fix them.
17:44:15 <cathy_> pcarver_: Some problems relate to linux version
17:44:22 <pcarver_> I use DevStack to get clean environments to clone networking-sfc into. But I haven't been able to install it successfully yet.
17:44:27 <igordcard> I would be very happy to help on fixing the rest of the rebases, but I can't do it just like that or the patchsets will clash; or I can help by commenting on the patchsets for the issues that I've been encountering
17:45:20 <cathy_> igordcard: since we are almost done with rebase, let louis and I finish them, then you can comment
17:46:00 <igordcard> cathy_, LouisF okay then, so I'll fully try it again when the head (https://review.openstack.org/#/c/238428/) gets updated
17:46:43 <s3wong> Guys: sorry, need to drop off. Talk to you guys in two weeks (since I would imagine next meeting will be canceled due to Thanksgiving).
17:46:44 <cathy_> There might be some comments which we forgot to incorporate in the new patch. If you see that, I apologize. Please re-add your comments to the latest rebase patches.
17:46:58 <igordcard> when the head works I will start my normal reviewing process on gerrit, otherwise comments will just get buried
17:46:59 <mohankumar> pccarver_ :  i used de vstack to pull sfc changes and its works for me
17:47:11 <cathy_> s3wong: yes, I will cancel next meeting. ttyl
17:47:20 <igordcard> cya s3wong
17:48:03 <LouisF> igordcard: we will update https://review.openstack.org/#/c/238428/
17:48:15 <igordcard> mohankumar, I'll get in touch with you offline
17:48:26 <cathy_> mohankumar: great. so everything works automatically?
17:48:37 <cathy_> mohankumar: without any glitch?
17:48:52 <ramanjaneya_> ramanjaneya_: igordcard :we will update the patch
17:48:53 <igordcard> LouisF, thanks, but please update only when all previous patches have been rebased, otherwise 238428 will still not work :(
17:48:57 <mohankumar> cathy_ : yes
17:49:13 <LouisF> igordcard: yes will do
17:49:30 <cathy_> pcarver_: maybe you can sync up with mohankumar to see what is the gap between you two
17:49:40 <pcarver_> mohankumar: did you write down the sequence of steps?
17:50:00 <mohankumar> pcarver_ : ok
17:50:06 <pcarver_> e.g., did you run stack.sh before or after installing networking-sfc?
17:50:29 <pcarver_> mohankumar: and if you can share your full local.conf that might help too
17:50:37 <ramanjaneya_> ramanjaneya_: steps already specified in the patch
17:50:49 <mohankumar> igordcard: can you talk to prithiv , i helped him to get sfc changes with devstack
17:51:03 <igordcard> maybe all interested parties can discuss in #openstack-neutron?
17:51:34 <igordcard> mohankumar, yes I have been in touch with him but he seems to be using an old version of the code, back from when networking-sfc was stackable... the head of networking-sfc is not stackable right now
17:51:34 <cathy_> ramanjaneya_: mohankumar so just follow the steps in the patch will work with no glitch?
17:52:03 <mohankumar> pcarver_: i 'l l  share c
17:52:52 <cathy_> mohankumar: Could you send the local.conf to everyone?
17:53:37 <ramanjaneya_> cathy_: will work if follow the steps in the patch
17:53:50 <mohankumar> cathy_: ok , i ve working code without patches added recently
17:54:24 <cathy_> mohankumar: ramanjaneya_ after we are done with OVS agent patch to fix all the failures, could you work on the devstack patch and the command line patch to fix the errors?
17:55:05 <mohankumar> cathy_ :  ok
17:55:10 <cathy_> I will go to the next topic before we run out of time
17:55:16 <cathy_> #topic Patch dependency issue and how we avoid cross damage to other patches due to change of one patch
17:55:19 <ramanjaneya_> ramanjaneya_: cathy_ :ok
17:55:27 <cathy_> mohankumar: ramanjaneya_ thanks!
17:56:28 <cathy_> In the future, I think whenever we upload a new patch which other patches depend on, let's run the gating tests of all the other patches to make sure there is no co-lateral damage before upload the patch. What do you think?
17:58:34 <igordcard> cathy_, the problem with the current patch dependency is that there are too many patches depending on each other so it's really hard to keep consistency unless you're rebasing everything everytime
17:59:08 <igordcard> cathy_, but in the future, with this big chunk merged, it won't be as difficult because patches will be smaller, less dependent, more specific
18:00:08 <pcarver_> cathy_: It's too late to fix now so we need to keep pushing forward to get a working base merged, but it would have been better to stubbed out the framework first so that we could have merged a series of simpler patches.
18:00:09 <igordcard> I understand it is difficult for you to have it properly resolved at this point, but this is the hardest time of all
18:00:12 <cathy_> igordcard: yes, agree. For now that is the issue we need to face since we break up the codes into multiple patches.
18:00:52 <cathy_> we are running out of time. we cna discuss more in next meeting
18:00:54 <cathy_> by everyone
18:01:10 <cathy_> pcarver_: agree
18:01:31 <igordcard> bye all
18:01:32 <pcarver_> I think once we get a working and reliably installable package, we can go back and refactor some things in smaller patches.
18:01:59 <cathy_> pcarver_: yes, we need to first merge the base working package
18:02:08 <cathy_> #endmeeting