17:14:21 #startmeeting service_chaining 17:14:22 Meeting started Thu Jan 12 17:14:21 2017 UTC and is due to finish in 60 minutes. The chair is LouisF. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:14:23 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:14:26 The meeting name has been set to 'service_chaining' 17:14:56 hi all apologies for late start - my train was late 17:14:59 Hi all - happy new year 17:15:10 hi LouisF, no problem 17:15:15 doonhammer: happy new year 17:15:20 hello 17:16:23 #topic agenda 17:16:58 last weeks we discussed the API ref, and the OSC client work 17:18:39 pcarver: is there progress on the api ref work? 17:19:31 LouisF: Sort of, indirectly. I've been working on both bgpvpn and sfc API ref. I was having devstack issues which prevented me from doing verification of all examples. 17:19:57 I've got it all sorted out on the bgpvpn side and running stack.sh right now on an sfc devstack. 17:20:09 pcarver: thanks 17:20:36 hopefully everything is all fixed up. Then I'm just going to run curl commands to validate the accuracy of all the examples and I should be done 17:21:09 pcarver: great 17:21:58 mohankumar: great timing - how is sfc for osc work? 17:22:13 Hi louis , its going good 17:22:53 Got some comments , will address tmrw 17:23:03 https://review.openstack.org/#/c/409759/ has some comments 17:23:17 LouisF: yes 17:23:41 Will address shortly 17:23:51 mohankumar: when will you post a patch to address comments? 17:23:55 mohankumar: ok thanks 17:25:10 LouisF: I wsbooked with othrt 17:25:24 mohankumar: ok understand 17:25:45 #topic latest patches 17:26:30 look like latest patches are encountering a tempest failure 17:26:57 for example http://logs.openstack.org/00/409800/2/gate/gate-tempest-dsvm-networking-sfc-ubuntu-xenial/e7994eb/ 17:27:58 indeed, I created https://bugs.launchpad.net/networking-sfc/+bug/1655618 for it 17:27:58 Launchpad bug 1655618 in networking-sfc "Tempest runs: intermittent single test failure" [Undecided,In progress] - Assigned to Bernard Cafarelli (bcafarel) 17:28:14 http://logs.openstack.org/62/409162/1/check/gate-tempest-dsvm-networking-sfc-multinode-ubuntu-xenial-nv/41b4466/ 17:28:37 bcafarel: thoughts on what the problem is? 17:29:29 Looks like a race condition, where a flow classifier from a previous test still is in database, when we want to create a new one 17:29:41 tempest tests use a new port each time, but the parameters are the same 17:30:19 I followed up on igordcard email, as this is a problem he got recently: 17:30:38 flow classifiers with same parameters, but different logical ports 17:30:57 you can create them, but they conflict when adding it to the port chain 17:31:12 bcafarel: that is valid functionality to block that case 17:31:27 http://lists.openstack.org/pipermail/openstack-dev/2017-January/110025.html 17:32:02 the reason is that when re-classification is done when a packet is received from the egress port of a SF 17:32:41 the N-tuple is the only way to distinguish the chain the packet is a part of 17:33:11 so ... the classifier N-tuples must be different 17:33:57 ah ok :/ 17:34:03 and hence the case Igor refers to where 2 classifers with same N-tuples but different logical source ports is blocked 17:34:16 LouisF: so effectively it's 1 classification per port chain 17:34:40 LouisF: no, 1 port chain per classification 17:34:51 igordcard: yes 17:35:11 tests on lines 602 and 1079 fail if the full conflict method is called: https://review.openstack.org/#/c/419212/1/networking_sfc/tests/unit/db/test_sfc_db.py 17:35:55 so this is another limitation of using the sfc-proxy in networking-sfc 17:36:15 which means that for the sfc graphs patch it's OK since the graphs require full encapsulation 17:36:31 igordcard: agree - using nsh-aware SF will remove this problem 17:36:58 then there is no need for proxy devices 17:37:03 LouisF: thanks for clarifying why the constraint exists 17:37:12 igordcard: np 17:37:26 great 17:37:27 thanks, I will look for another solution for the tempest failure then 17:38:00 bcafarel: is there a way to enure the db is flushed after a test? 17:38:06 ensure 17:38:54 I do not know yet, but I will look into it, as this would fix the problem indeed 17:39:22 bcafarel: ok thanks 17:40:12 bcafarel: maybe post a question to openstack-infra for help 17:41:42 bcafarel: thanks 17:41:47 LouisF: np, I will also check with tempest folks 17:42:16 #topic ocata work 17:42:56 symmetric chain patch https://review.openstack.org/#/c/410482/ 17:43:06 all - please review 17:43:42 sfc graph patch https://review.openstack.org/#/c/388802/ 17:43:49 all - please review 17:44:44 doonhammer: on ovn integration - i see you posted a patch to ovs 17:44:47 LouisF: yep that is not expected to have any further changes except its dependency 17:45:06 igordcard: thanks 17:45:16 LouisF: sfc graph api patch will not depend on the nsh patch anymore, but rather on a different patch I will submit, which simply enables MPLS encap without proxying 17:45:23 LouisF: Yes trying it in 17:45:29 or at least reviewed 17:46:20 doonhammer: for the sfc to ovn driver - have you started work on that? 17:47:07 LouisF: I have a version but it is pretty old 17:47:43 doonhammer: that is on github? 17:47:56 LouisF: yes 17:48:28 do you need help on that? 17:48:46 LouisF: Would appreciate it 17:49:24 all - volunteers on sfc/ovn driver welcome 17:49:43 just 1 thing, I've also submitted a graph patch including db and plugin logic/code, I'm not expecting major changes to it so I'd say it's ready for an initial review: https://review.openstack.org/#/c/419212/ 17:50:28 igordcard: thanks - all please review 17:51:14 #topic other items 17:51:31 any other items to discuss? 17:51:48 LouisF: is the team going to the PTG? 17:52:50 igordcard: i don't think i will be there - not sure about cathy 17:53:28 this is in atlanta in feb https://www.openstack.org/ptg/ 17:54:33 ok anything else? 17:55:20 ok thanks all 17:55:22 bye 17:55:25 I will be there, if anyone from the team can come, great 17:55:28 bye 17:55:45 #endmeeting