17:13:49 #startmeeting service_chaining 17:13:50 Minutes: http://eavesdrop.openstack.org/meetings/networking_sfc/2015/networking_sfc.2015-12-10-17.12.html 17:13:51 Minutes (text): http://eavesdrop.openstack.org/meetings/networking_sfc/2015/networking_sfc.2015-12-10-17.12.txt 17:13:52 Log: http://eavesdrop.openstack.org/meetings/networking_sfc/2015/networking_sfc.2015-12-10-17.12.log.html 17:13:53 Meeting started Thu Dec 10 17:13:49 2015 UTC and is due to finish in 60 minutes. The chair is LouisF. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:13:54 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:13:58 The meeting name has been set to 'service_chaining' 17:14:06 ok, that's better 17:14:08 hi all 17:14:22 hey LouisF 17:14:25 cathy is away today 17:14:34 o/ 17:14:42 agenda topics? 17:14:50 hello 17:15:20 LouisF: I think the main topic is still installation. I haven't tried Cathy's new instructions, but I'd like to hear who has. 17:15:48 I think we should try to merge a devstack change if it's working consistently for people. 17:15:51 pcarver: agree 17:16:57 oh, another topic I wanted to raise is database table naming. I'm wondering if we should group everything together with an sfc prefix 17:17:13 e.g. like the ml2 tables are 17:18:12 pcarver: can you suggest an example 17:18:57 #topic installation 17:19:23 has anyone tried the latest devstack? 17:19:25 LouisF: example related to the devstack installation topic or the table naming topic 17:19:54 pcarver: latter lets defer though 17:20:01 let's talk devstack first. Who has tried Cathy's latest instructions as posted to the wiki and were you successfult? 17:20:41 https://wiki.openstack.org/wiki/Neutron/ServiceInsertionAndChaining 17:21:28 I haven't as I'm waiting for the flow classifier 17:21:54 LouisF, Flowclassifier changes are done ? 17:22:52 mohan_kumar, igordcard_ the flow classifier should work currently 17:23:18 LouisF , okay 17:23:47 LouisF: where are the flow classifier methods' implementation? 17:24:17 https://review.openstack.org/#/c/233858/15/networking_sfc/services/flowclassifier/plugin.py 17:24:18 igordcard_: they are implemented in agent.py 17:24:41 LouisF: We need to have it in plugin.py as well 17:24:56 LouisF: Might be required by other drivers 17:25:11 LouisF: so then this file should implement the methods right? https://review.openstack.org/#/c/227100/30/networking_sfc/services/sfc/plugin.py 17:25:11 vikram_: agree for other drivers 17:25:17 I don't see the wiki instructions fetching 233858 or 253679 (the latest devstack change) 17:25:49 LouisF: Is the changes done? Can't find them 17:25:50 igordcard_: yes 17:26:14 vikram_: which chnage are you refering to? 17:26:15 so do the wiki instructions include flow classifier by some other means? Or does following those instructions leave out the fc? 17:26:37 LouisF: adding FC interfaces in plugin.py 17:27:01 pcarver: the wiki will install the agent that implements the FC 17:27:06 LouisF: As pointed out earlier some drivers may required FC's notifications as they come 17:27:15 vikram_: +1 17:27:38 LouisF: I think we discussed this before 17:28:00 LouisF: but could not find the code for it.. so just wondering 17:28:10 vikram_: agree will add to https://review.openstack.org/#/c/233858/15/networking_sfc/services/flowclassifier/plugin.py 17:28:32 LouisF: ok 17:28:35 LouisF: :) 17:28:45 but that is not required for the ovs driver implementation 17:29:13 LouisF: I don't see how it receives the signals from the API.. 17:30:06 to implement the port chain and associated classifiers the OVS agent queries the DB to get the FC info 17:30:20 then sets up the appropriate flows 17:31:07 LouisF:+1 17:31:29 oh, okay 17:32:14 set _parse_flow_classifier in agent.py 17:32:16 see 17:33:13 back on topic I will update the wiki to include latest devstack 17:33:32 then please try the install procedure 17:34:17 LouisF , sounds good ! 17:34:36 LouisF: quick doubt, this should work with ingress=egress port pairs right? 17:34:54 igordcard_: yes it will, we have tested that 17:35:00 LouisF: thanks 17:37:26 once a chain has been created dump flows should show 17:37:29 cookie=0x97c3b95c3db61742, duration=76753.949s, table=0, n_packets=4911361, n_bytes=481313378, idle_age=0, hard_age=65534, priority=10,ip,nw_src=10.0.0.15,nw_dst=10.0.0.7 actions=push_mpls:0x8847,load:0x100ff->OXM_OF_MPLS_LABEL[],set_mpls_ttl(255),output:36 cookie=0x97c3b95c3db61742, duration=85074.214s, table=0, n_packets=5007569, n_bytes=490745445, idle_age=0, hard_age=65534, priority=10,mpls actions=resubmit(,5) cooki 17:37:46 on br-int 17:38:44 cookie=0x97c3b95c3db61742, duration=85074.214s, table=0, n_packets=5007569, n_bytes=490745445, idle_age=0, hard_age=65534, priority=10,mpls actions=resubmit(,5) 17:39:01 cookie=0x97c3b95c3db61742, duration=76753.885s, table=5, n_packets=4911360, n_bytes=481313280, idle_age=0, hard_age=65534, priority=1,mpls,dl_dst=fa:16:3e:07:71:2b,mpls_label=65791 actions=pop_mpls:0x0800,output:3 17:40:04 LouisF: looks good, thanks for the paste 17:40:05 i will post these on the wiki 17:40:50 Louis, add the steps you followed for enable traffic dumps as well 17:41:14 on service VMs 17:41:16 ok 17:42:15 sudo tcpdump -eni qvo7e79c62d-23 17:43:17 ok please try installation procedure on wiki 17:43:30 LouisF , Thanks 17:43:55 #topic database naming 17:44:15 pcarver: can you give an example 17:45:00 LouisF: so if you do "show tables;" in the database, the SFC tables are scattered around 17:45:30 if you look at the list of tables, on the other hand you'll see that all the ml2 table names start with ml2_ 17:45:55 NSX and Nuage tables start with nsxv_ and nuage_ respectively 17:46:16 I'm wondering whether there's a concern over "polluting" the database namespace 17:47:18 should we have sfc_port_chains and sfc_flow_classifiers so that all the SFC tables are together in the listing 17:47:49 and so that it's clear which tables are part of the SFC sub-project as opposed to core Neutron or some other sub-project or extension 17:48:07 pcarver: agree that would help 17:48:43 others? 17:48:46 anyone else have an opinion? 17:49:01 I didn't post this to a review because I wanted to get input from the team first 17:49:40 pcarver, +1 . It's good to have common prefix , i too thought once 17:50:14 pcarver: we no dissenting voices ... 17:50:21 we have 17:50:29 if there are no objections, I'm going to post this to the DB related files on review.o.o 17:50:44 pcarver: ok 17:51:01 a nuisance to rename all the tables I suppose, but I think we'll be happier in the long run 17:52:23 we can do that but we reallt need to focus on getting installation tested and the implementation evaluated on as many testbeds as possible 17:53:16 ok any other questions, topics? 17:54:06 going, going... 17:54:19 thanks all 17:54:41 bye 17:54:43 Bye 17:54:45 bye 17:54:53 @endmeeting 17:55:00 #endmeeting