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