13:01:06 #startmeeting tricircle 13:01:07 Meeting started Wed Dec 21 13:01:06 2016 UTC and is due to finish in 60 minutes. The chair is joehuang. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:01:08 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:01:10 The meeting name has been set to 'tricircle' 13:01:19 #topic rollcall 13:01:25 #info liukun 13:01:26 #info joehuang 13:01:32 Hello 13:01:34 #info dongfeng 13:01:37 #info xiulin 13:01:43 #info Wucheng 13:01:45 #info Yipei 13:01:50 #info JunSik 13:02:18 #info zhiyuan 13:02:59 #topic VxLAN L2 networking/L3 DVR issue 13:03:33 #info liuzyu 13:03:35 last week we discussed VxLAN network across Neutron 13:04:09 and one action is to contact Neutron team how we can contribute to the VTEP in port 13:04:23 but not received response yet 13:04:38 and also not see any new progress in this topic recently 13:05:20 so I discussed with Zhiyuan offline to find out whether we can have some way to address this issue if no improvement from Neutron 13:05:47 Zhiyuan, could you share the idea in short 13:07:07 ok, give me some time to type :) 13:07:27 fine 13:12:00 let's say we have one vm port1 created in pod1 and one vm port2 created in pod2, to connect port1 and port2, we create a shadow port for port1 in pod2 and also a shadow agent in pod2, so the ovs agents in pod2 will get information of shadow port1 and the VTEP information from the shadow agent, and create the VxLAN tunnel to pod1 13:12:53 the shadow agent has the same host ip as the agent port1 in pod1 is bound to 13:14:01 yes, and the shadow agent will not work as RPC server 13:14:17 so no RPC message will be sent to the shadow agent 13:14:55 but L2 population will carry all fdb entry including the shadow port to local agents 13:15:11 this is the rough idea 13:15:16 at the same time 13:15:19 the intuition is that we "cheat" local Neutron server in the other pod with shadow ports and shadow agents information, to let local Neutron server consider the remote ports as local ones 13:15:31 are all the vm ports in one pod share the same agent? 13:15:51 to Yipei, this mode could work as L2GW mode 13:16:18 i.e, all shadow ports are located in one shadow L2GW agent 13:16:42 ok, i see 13:17:21 otherwise, each agent in one pod has shadow agents in other pods, if shared VxLAN networking is needed in those pods 13:17:28 but if we want tunneling from compute node to compute node, then they are on different shadow agents just like the virtual site 13:17:58 to Zhiyuan, this is the CN <-> CN mode 13:18:23 yes 13:18:40 if only one shadow agents for one pod, then it's CN(s) -> L2GW mode 13:18:56 And one more point 13:19:34 I also think that the DVR mac issue(can't recogized by the other OpenStack) can also be addressed by this mode 13:19:49 i.e, introduce shadow DVR mac 13:20:10 as shadow agent 13:20:34 to Junsik, do you think it's feasible? 13:22:57 hello, Junsik? 13:22:58 Yes, I think so. 13:23:26 and others' thought? 13:25:21 ok 13:25:40 any questions 13:27:44 This is one interesting direction we can move, and it's fully decoupled from Neutron implementation 13:28:24 and we can work on this direction and keep eye on the Neutron's improvement at the same time 13:29:14 yes, need to test if this solution works 13:29:32 #info one idea is to use shade ports/shadow agents to address VxLAN network across Neutron 13:29:53 #info poc test is needed to see if it's feasible 13:30:05 great! 13:31:25 who are interested in the poc test of this idea? 13:32:06 I think for the poc can just hard code to create shadow ports/agents in local neutron plugin 13:32:17 and to see if it works 13:33:53 maybe I have a try 13:34:04 thanks 13:34:34 #topic Ocata feature development review 13:35:25 hello, let's have a short review on the feature development, please describe in short thanks, and discuss as needed 13:36:14 for me, the scripts for multi-region gate/check test job is almost ready 13:36:39 for me, 1) go on with the table clean work and spec file. 2) write the release note of resource routing api. 13:36:50 need to submit patch and wait for review/approvement from 3 repositories :) 13:37:19 to Dongfeng, yes saw and reviewed your patches 13:40:17 some questions exist in the inline comments for each patch, after they are fixed I will update the patch. 13:40:35 1) spec for bridge network combination has been merged 2) resource deletion, manual installation guide, got +2 3) implementation of bridge network combination, dvr support, under review 13:40:38 there are lots of patches in the review queue 13:41:04 4) recently i also submit the patch for xjob reliability improvement 13:41:22 to Zhiyuan, great job, you have submitted so many patches 13:41:23 for lbaas, i already understand how neutron-lbaas works with agent, but still have some problem with octavia. plan to install tricircle with octavia, test whether it works to add members from other pods, and try to understand how octavia works 13:41:55 to Yipei, very good 13:41:57 I am doing port resource update 13:42:40 for members from other pods, may only IPs are applicable, using port may not work unless we have shadow ports there 13:43:02 oh, yes 13:43:02 to Xiulin, good, look forward to your new patch 13:43:31 ok 13:44:26 to xiulin, please confirm that the fields which are update-able for network/subnet/port compared to Neutron API document 13:45:18 i will 13:45:46 there are also some committer which are not able to attend the meeting 13:47:15 so please review the patches by searching https://review.openstack.org/#/q/project:openstack/tricircle 13:47:47 sorry /s which who 13:48:38 #topic open discussion 13:48:49 any other topics? 13:49:23 no from me 13:49:29 no for me 13:49:31 Christmas and New year is approching 13:49:44 no 13:49:58 ^_^ 13:50:21 so wish all of us have a pleasant holiday 13:50:37 thanks joe 13:50:51 and a better 2017 13:51:07 and wish Tricircle can be used in production in 2017 13:51:18 :D 13:51:24 :) 13:51:24 :) 13:51:43 :) 13:51:47 good, if no more topic, let's conclude the meeting 13:51:57 thank you for attending the meeting 13:52:15 #endmeeting