01:00:42 #startmeeting tricircle 01:00:43 Meeting started Wed Nov 15 01:00:42 2017 UTC and is due to finish in 60 minutes. The chair is zhiyuan. Information about MeetBot at http://wiki.debian.org/MeetBot. 01:00:44 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 01:00:47 The meeting name has been set to 'tricircle' 01:01:25 hello 01:01:32 i would like to discuss some implementation details of our features one by one 01:02:22 #topic distinguish the source of requests 01:03:31 after discuss offline with xuzhuang, we find that one problem for this feature is that the function exposed by neutronclient doesn't have header parameter 01:04:11 so we cannot set some labels in the header to distinguish request from local/central 01:04:48 xuzhuang's previous patch is to set labels in query string, but i think this is not a good way 01:05:50 I have finished the first version code through setting source tag into req.params. The result of testing in a running openstack is the request source tag can be get in central neutron. But it's a pity that, central neutron can't transform the source tag into context. So using params is failed. 01:06:39 we may need to add this to oslo.context, and neutron-client for this field configuration 01:06:55 i assume that you can set the label via "ctx.label = label" 01:07:41 one way without changing neutron-client is to set the module level value USER_AGENT 01:08:06 abd neutron-client will put USER_AGENT in header 01:08:17 s/abd/and 01:09:54 yes 01:10:10 this field itself is to discribe the source of the request 01:10:37 ok, I will try to use USER_AGENT 01:12:34 and for setting the field in context object, i think the code looks like this 01:13:19 ctx = req.environ['neutron.context']; ctx.label = label; req.environ['neutron.context'] = ctx 01:13:58 the previous filter will construct the context object and put it into req.environ 01:14:51 you need to confirm that the previous filter exactly put context object in req.environ['neutorn.context'] 01:17:17 There is no user_agent in context 01:17:42 yeah, but you can still do "ctx.user_agent = xxx" 01:18:04 ok 01:18:07 you can dynamically add field to python object 01:18:23 ok, Got it 01:18:36 fine, then next 01:18:56 #topic "LBaaS with tricircle" 01:19:40 hi yipei, I think michael has identified the problem 01:20:13 "the issue here is the gateway neutron gave us for the subnet is different than the one the amphora is receiving via DHCP" 01:20:29 this is true for our tricircle environment 01:21:01 hi, zhiyuan, yes, but he is oblivious of the additional route table may lead to failure for finding missing gateway ip 01:21:04 octavia query central neutron server to get gateway ip, this is different from the local neutron gateway ip 01:21:11 yes 01:22:00 but this is not a bug of octavia, in a normal setup, the route in table 1 is a onlink route 01:22:03 default via 10.0.0.1 dev eth1 table 1 onlink 01:24:00 o/ 01:24:06 ok, i see. so do we need to change the way we set gateway ip in tricircle? 01:24:50 hi johnsom, please 01:25:32 Just saying Hi and I can answer questions if you have them 01:28:58 i have a question, octavia queries the subnet gateway and set it in the route of table 1, so dhcp request will not change the route, is that correct? 01:28:59 to zhiyuan, maybe we can make central neutron return the real gateway ip in local neutron? 01:30:04 zhiyuan Correct, we honor the gateway neutron gives us for the neutron subnet the VIP is on. 01:30:08 to yipei, but central neutron need to know gateway ip of which local neutron to return 01:33:02 The rule and route table are there to make sure the traffic from the VIP goes back out the right interface. This allows members to access the VIP and get the response back from the appropriate MAC, etc. 01:34:01 johnsom, if the subnet doesn't have a gateway ip, will the route be set? 01:34:06 No 01:34:44 Yipei, so i think we have a work-around, to create a subnet without gateway ip 01:35:32 https://github.com/openstack/octavia/blob/master/octavia/amphorae/backends/agent/api_server/templates/plug_vip_ethX.conf.j2#L44 01:37:08 I still don't quite understand why if they are on the same subnet it would need to go to the default route... 01:37:37 It's as if you are using DVR and the arp tables are not correct. 01:38:52 johnsom, in tricircle, one subnet in central neutron will be created in several local neutron, to avoid ip conflict, we allocate a gateway ip for each local neutron 01:39:25 so the gateway IPs of the same subnet in different local neutron are different 01:41:36 eh... but in my environment where octavia is installed alone, the gateway ip port does not exist, the route of table 1 is still added 01:42:57 Yipei, what about the curl traffic? 01:43:53 It would likely bypass the routing table and use the default routing table with the other gateway 01:44:41 i checked, same issue, haproxy cannot respond curl with source if as VIP 01:44:54 s/if/ip/ 01:48:12 Sorry, I need to sign off now. 01:49:27 bye, johnsom, thanks for your help 01:49:46 bye johnsom, thank a lot 01:50:26 Yipei, i think we just try to use a subnet without gateway 01:50:53 you mean the gateway port does not exist? 01:51:10 no, create a subnet without gateway 01:51:17 if the subnet has no gateway, how about l3 traffic 01:51:18 by default the ip is .1 01:53:07 i will test it 01:54:54 the main problem is that octavia queries central neutron to get gateway ip 01:55:18 this is always different from the local neutron gateway ip 01:55:39 oh, i see 01:55:47 so even you attach a router, tricircle with LB still doesn't work 01:56:04 cool, i think it will work 01:56:44 so we have a limited LB 01:57:36 :( 01:58:00 maybe we need to figure out a way to adapt the route of table 1 in future 01:58:37 if we can distinguish the request from octavia, we can reply the local neutron gateway ip 02:00:15 yes, i can investigate it 02:00:25 hope we can implement a full lbaas 02:01:00 hope so 02:01:09 yes, need to find a way to address this issue 02:01:28 a quick pass of the last topic 02:01:39 #topic QoS with tricircle 02:02:03 glad to see that all the tests have passed! 02:02:16 but my last comments are not addressed 02:02:28 the updated patch only rebase the master change 02:03:18 sorry, maybe i missed it, will double check and update it 02:04:19 to Yipei, Zhiyuan is talking about QoS 02:04:27 to zhiyuan, i modified your review, now adding qos bound network unit tests 02:04:27 Yipei, we have moved to the QoS topic :) 02:04:43 oh, sorry 02:05:35 zxh, great, i think the patch need to rebase again, i see "Merge Conflict" in the review page 02:06:46 ok, i know, thinks 02:07:21 beyond this are there any other work we can do? we also have two people freedom. 02:07:26 oh, time's up, let's end our meeting 02:07:47 song, let's discuss in openstack-tricircle 02:07:56 good 02:08:04 #endmeeting