17:01:32 <cathy__> #startmeeting service_chaining
17:01:33 <openstack> Meeting started Thu May 12 17:01:32 2016 UTC and is due to finish in 60 minutes.  The chair is cathy__. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:01:34 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:01:37 <openstack> The meeting name has been set to 'service_chaining'
17:02:06 <cathy__> hi everyone
17:02:08 <LouisF> hi cathy__
17:02:08 <scsnow> hi
17:02:13 <yamahata> hello
17:02:13 <pcarver> hi
17:02:18 <doonhammer> Hi Cathy
17:02:25 <georgewang> hi
17:02:36 <cathy__> Let's start
17:02:44 <vishnoianil> hi everyone
17:02:59 <cathy__> #topic Status update
17:03:13 <mohankumar> hi
17:03:16 <cathy__> 1. Add support for Querying Driver capability for SFC functionality support
17:05:05 <cathy__> scsnow: did you take this work?
17:05:22 <cathy__> or maybe someone else?
17:05:40 <scsnow> I did a quick look into neutron microversions proposal and it seems for me, that it does not what we need
17:06:03 <scsnow> so we would need to work on spec to define requirements
17:06:42 <regXboi> so.. I would point out that isn't just neutron's microversioning - it's openstack's
17:07:08 <scsnow> currently it's implemented only in nova
17:07:40 <scsnow> and that's about API capabilities
17:07:57 <LouisF> regXboi: only implemented in nova?
17:08:26 <LouisF> scsnow: +1
17:08:45 <regXboi> I would disagree with that statement
17:08:51 <regXboi> but that is neither here nor there
17:09:31 <cathy__> scsnow: I agree with you that It is about API cap, not the driver cap.
17:10:58 <LouisF> scsnow: agree microversioning does not really expose different driver capablities
17:11:18 <cathy__> scsnow: Yes, we need a spec on the requirement and mechanism how to do it to satisfy the requirement. Could you start working on this?
17:11:37 <scsnow> per my understanding we need to extend sfc api by adding additional method let's say get_driver_capabilities
17:11:48 <LouisF> does neutron itself address differences in the ml2 driver capablities?
17:11:56 <cathy__> scsnow: yes, agree on that direction.
17:11:56 <scsnow> and each driver should implement it to report its capabilities
17:12:42 <LouisF> it must exist as a issue with neutron itself
17:13:10 <cathy__> Another aspect is that if a user specify a SFC requirement in the API, the API needs to query the driver cap to see if it can meet that req, if not reject the API request
17:13:21 <scsnow> LouisF, I think no. At least there is not way to identify whether specific type driver in supported in specific mech driver
17:13:23 <mohankumar> LouisF: good question , thought of same
17:13:42 <LouisF> there are different ml2 drivers and they certainly don't offer the  same support
17:13:45 <pcarver> LouisF: The one place I know Neutron does something has to do with VLAN transparency. I don't think it's part of ML2 specifically, but there's a Neutron API to check whether a network will pass VLAN tags transparently between VMs
17:13:57 <LouisF> pcarver: yes i saw that
17:14:51 <LouisF> does the same problem exist with neutron and there is a solution already
17:15:13 <cathy__> LouisF: scsnow mohankumar pcarver Yes, I think we should investigate whether Neutron has similar mechanism since Neutron should have the same problem.
17:15:14 <LouisF> i would prefer a common solution to this
17:16:29 <cathy__> But the case could be that Neutron has not done it or not done it in a generic way. Agree with Louis that this is a generic issue not specific to SFC and we should implement a generic mechanism that can be used by other features in the future
17:16:41 <LouisF> that said we should also look into the implications of microversioning the api
17:17:04 <LouisF> the networking-sfc api that is
17:17:36 <cathy__> LouisF: microversioning should be done for all networking-sfc API, not just this specific one\
17:18:18 <LouisF> cathy__: you mean neutron api
17:18:25 <scsnow> I also prefer generic approach. But currently neutron does not provide anything useful for our case. Even API microversioning is not implemented there.
17:19:04 <cathy__> LouisF: no, we do the API for SFC but do it in a generic way
17:19:16 <cathy__> or try to do it in a generic way
17:19:19 <mohankumar> Generally team will update their driver support to marketplace : https://www.openstack.org/marketplace/drivers/
17:19:33 <LouisF> scsnow: we should adopt what neutron does
17:19:41 <cathy__> scsnow: let's just do it for SFC driver capability for now
17:20:32 <cathy__> But the query mechanism should be easily extended for querying more capability or new capability in the future
17:21:03 <scsnow> cathy__, ok. can someone would help me to work on spec? at least define the list of driver capabilities, i.e. ability to handle symmetric chains and so on
17:21:13 <cathy__> LouisF: what do you mean by adopt what Neutron does? Does Neutron have the mechanism of querying the driver cap for Neutron API feature support?
17:21:38 <LouisF> cathy__: i meant neutron microversioning
17:21:41 <s3wong> sorry, late (again)
17:21:43 <cathy__> scsnow: I can help you on that
17:21:49 <scsnow> cathy__, thanks
17:21:51 <LouisF> scsnow: can help
17:21:59 <scsnow> LouisF, thanks
17:23:06 <cathy__> OK, Louis and I will send you a list of API caps that a driver can support.
17:23:28 <cathy__> Ok, let's go to next item
17:23:33 <LouisF> http://specs.openstack.org/openstack/neutron-specs/specs/liberty/microversioning.html
17:24:01 <cathy__> 2. Networking-sfc SFC driver for OVN
17:24:13 <cathy__> John, are you there?
17:24:25 <doonhammer> yes cathy
17:25:05 <doonhammer> I have been working with Ryan/regXboi
17:25:16 <doonhammer> to merge the changes into a patch set
17:25:34 <cathy__> doonhammer: great!
17:25:43 <doonhammer> I have sfc and ovn done now working on OVN
17:25:47 <cathy__> Yes, I saw emails in the OVS alias
17:25:53 <s3wong> doonhammer: seems like there are changes in OVS, logically that should go in first
17:26:23 <cathy__> s3wong: yes, that is where they have been working
17:26:28 <s3wong> doonhammer: and I guess next would be networking-ovn actually adding the support for the new NB schema
17:26:35 <doonhammer> yes but they are harder :-)
17:26:38 <regXboi> well... not exactly
17:27:03 <s3wong> doonhammer: networking-sfc changes (if any) should be last... is the OVN SFC driver going to be in networking-ovn repo or networking-sfc?
17:27:10 <regXboi> with respect to the patch set for ovs/ovn, having the other patch sets to refer to for E2E testing will help the ovs/ovn review process immensely
17:27:31 <doonhammer> once I have a clean version I need to convert the ovs/ovn code to use port-pair model ala Russell's approach
17:27:54 <cathy__> regXboi: Ok, got it. We have done E2E testing for the OVS driver path.
17:28:03 <LouisF> doonhammer: we need to finalize the extensions to the ovn nb schema
17:28:43 <cathy__> regXboi: We are working on automating the E2E testing and will post the testing scripts soon. Is this the help you need?
17:28:53 <doonhammer> LouisF: yes a lot of work remains - I just wanted to get something that showed it would work then the really work begins
17:29:00 <regXboi> cathy__: the OVS driver patch doesn't really help
17:29:21 <cathy__> doonhammer: :-)
17:29:43 <regXboi> cathy__: automation is always good, but the ovn/ovs patch will needs its own unit tests as part of its commit, since we can't depend on openstack there
17:29:45 <LouisF> doonhammer: sounds good
17:30:08 <regXboi> cathy__: on the other hand, being able to say that the patch also works with n-ovn and n-sfc does carry weight in the review process
17:30:27 <cathy__> regXboi: I see. So what you need is the UT and E2E testing on the OVN path
17:30:36 <regXboi> cathy__: ack
17:30:49 <doonhammer> we probably need a simple dumb VNF to test - I have been using our NGFW in my test cases
17:32:10 <s3wong> cathy__: this begs the question... if the SFC drivers live in a different repo (i.e., such as ODL driver), obviously it is strange for each SDN / networking repo which has SFC driver to have functional test on SFC features, how are we (networking-sfc) supposed to provide a CI test framework to ensure all drivers are sane (like Neutron does)?
17:32:47 <cathy__> doonhammer: yes, for the testing, we do not really needs real VNF functionality since we are testing the chain, not the VNF functionality
17:33:41 <LouisF> doonhammer: we do need to account for the vnf insertion mode: bump in wire, l2, ..
17:33:45 <cathy__> s3wong: That is a good question. That is why I have the topic discussion in last meeting on which repo the drivers should go
17:34:44 <doonhammer> I think we need end to end testing especially when we have a chain
17:34:59 <cathy__> s3wong: I guess each driver needs to ensure their "insane" if the driver resides outside of networking-sfc. But for driver that resides inside networking-sfc, networking-sfc team and CI needs to ensure that
17:35:25 <regXboi> so... having drivers live inside of n-sfc that depend on other projects is a recipe for a mess
17:35:39 <regXboi> look at the time being spent pulling the *aaS code out of neutron
17:36:06 <regXboi> the contract should be API driven, and then the other projects can have unit tests for those pieces of the API
17:36:55 <LouisF> regXboi: i think that was agreed to at the last meeting
17:37:02 <cathy__> s3wong: make sense. For those drivers that reside inside networking-sfc, they are SFC's reference implementation and any new API extensions need to be supported by those drivers and comprehensive testing needs to be ensured
17:37:03 <doonhammer> regXboi: +1
17:37:08 <cathy__> s3wong: make sense?
17:37:09 <regXboi> LouisF: it was - I'm hoping we aren't reopening it :)
17:38:11 <doonhammer> one of the comments regXboi had on my code was that and I am fixing it. Once we have and OVS and OVN driver would be good to do a review and make sure we are doing the right abstraction
17:38:12 <s3wong> cathy__: I think the model for even the stadium projects is that drivers are decomposed just like Neutron; my gut tells me most drivers will reside OUTSIDE of networking-sfc repo (just like Neutron)
17:38:40 <s3wong> cathy__: so we may (eventually) need to provide a driver CI like Neutron
17:39:16 <cathy__> s3wong: could you look into the driver CI for networking-sfc?
17:39:32 <cathy__> s3wong: similar to what Neutron does?
17:39:37 <s3wong> cathy__: I can take a look at how Neutron does it :-)
17:40:13 <cathy__> Ok, this item is assigned to you since most other people are full on hand:-)
17:41:55 <cathy__> #action s3wong will investigate the driver CI for networking-sfc.
17:43:33 <cathy__> doonhammer: regXboi Very good progress. Thanks! Let us know if you need any help.
17:43:57 <cathy__> 3. Networking-sfc SFC driver for ODL
17:44:23 <cathy__> AFAIK this driver spec is approved. How is the code development going?
17:44:31 <cathy__> yamahata: are you there?
17:44:38 <cathy__> vishnoianil: ?
17:44:42 <yamahata> cathy__: yes?
17:44:58 <cathy__> yamahata: vishnoianil any update on the code side?
17:44:59 <yamahata> So far it's up to vishnoianil.
17:45:11 <yamahata> no patch isn't uploaded yet.
17:45:17 <yamahata> patch for code
17:45:40 <doonhammer> cathy: once I have the basic version done will need help looking at all the edge conditions - I will start a list on issues I see - any place I can post it?
17:45:46 <cathy__> vishnoianil: are you there? Are you working on the code patch?
17:46:46 <cathy__> doonhammer: You can either send it via emails or post it on our wiki project wiki page.
17:47:19 <doonhammer> cathy: ack
17:47:42 <cathy__> doonhammer: or we can have a f2f meeting to go through them if that is more effective.
17:47:50 <vishnoianil> cathy__, sorry doing double shifting between opendaylighjt tsc meeting and this one
17:48:00 <vishnoianil> cathy__, i already pushed the yang models to opendaylight project
17:48:21 <vishnoianil> and the next step is to write the driver in networking-odl
17:49:24 <cathy__> vishnoianil: good progress! Thanks for your work!
17:49:49 <cathy__> 4. Networking-sfc integration with ONOS completion status update
17:50:10 <mohankumar> cathy__ , code already developed and we tested internally, driver code already magred to networking-onos sub-roject repo
17:50:21 <mohankumar> https://github.com/openstack/networking-onos/blob/master/doc/source/devref/sfc_driver.rst
17:50:21 <mohankumar> https://github.com/openstack/networking-onos/blob/master/networking_onos/services/sfc/driver.py
17:50:21 <mohankumar> https://github.com/openstack/networking-onos/blob/master/doc/source/devref/flowclassifier_driver.rst
17:50:21 <mohankumar> https://github.com/openstack/networking-onos/blob/master/networking_onos/services/flowclassifier/driver.py
17:51:10 <cathy__> mohankumar: Great. Yes, I know codes have been merged. Have you uploaded UT and functional testing codes too?
17:51:53 <mohankumar> yes cathy__  Test codes already wrote
17:52:07 <mohankumar> ** UT
17:52:34 <mohankumar> functional Test , i need to check
17:52:38 <cathy__> Ok, great!
17:52:46 <cathy__> Now last one
17:52:53 <cathy__> 5. Tacker Driver for networking-sfc
17:53:12 <cathy__> LouisF: has this spec been merged in tacker repo?
17:53:25 <LouisF> need final review of https://review.openstack.org/#/c/290771/
17:54:30 <LouisF> is has had comment and i have updated some time ago
17:54:55 <cathy__> Ok, you may want to ping Scridhar on this to get it reviewed and merged so that coding can be started.
17:55:08 <LouisF> cathy__: will do
17:55:09 <s3wong> LouisF: yeah, you updated the spec during the summit, and most people probably missed it :-)
17:55:26 <LouisF> s3wong: i will ping again
17:55:27 <cathy__> I mean final review
17:55:47 <cathy__> LouisF: Good. Thanks.
17:56:08 <cathy__> s3wong: Could you please help on getting the final review done and the patch merged?
17:56:46 <s3wong> cathy__, LouisF: a lot of comments came from trozet, and during the summit, he and I spoke --- and he indicated he is fine with the current version
17:57:11 <LouisF> s3wong: i have pinged
17:57:28 <s3wong> cathy__, LouisF: given the understanding of VNFFG in general, the +2s will likely have to come from sridhar_ram and me
17:57:28 <cathy__> LouisF: s3wong good. Thanks!
17:57:35 <LouisF> s3wong: i incorporated his comments
17:58:34 <s3wong> LouisF: yes, I noticed :-)
17:59:17 <cathy__> We do not have time for the other topics. We have made very good progress on our driver integration work!
17:59:40 <cathy__> Keep up the good work! Bye for now
17:59:42 <LouisF> bye
17:59:44 <scsnow> bye
18:00:06 <doonhammer> bye
18:00:13 <cathy__> #endmeeting