13:00:25 #startmeeting tricircle 13:00:26 Meeting started Wed Dec 14 13:00:25 2016 UTC and is due to finish in 60 minutes. The chair is joehuang. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:00:26 hi 13:00:27 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:00:29 The meeting name has been set to 'tricircle' 13:00:41 #topic rollcall 13:00:53 #info joehuang 13:00:54 #info zhiyuan 13:01:00 #info longxiongqiu 13:01:02 #info Yipei 13:01:05 #info jiawei 13:01:05 #info ronghui 13:01:16 #info liukun 13:01:33 #info xiulin 13:02:26 #topic VxLAN L2 networking across Neutron feature 13:02:55 currently the combined bridge network spec is approaching to be merged 13:03:14 but still want to wait for more review comment for one to two week 13:03:31 and the code is also submitted by zhiyuan for review too 13:03:38 #info liuzeyu 13:03:59 it's time for use to start the discussion of VxLAN L2 networking across Neutron 13:04:15 as you know, currently only shared VLAN is supported 13:05:06 Junsik told me he is not able to attend the meeting, but he sent me some info about his experiment on L2 networking across openstack cloud 13:05:31 your thoughts? 13:06:30 how did Junsik do the experiment? manually add the flow? 13:07:00 To connect Multi-region OpenStack instances, I add an additional bridge named "br-cap" and configure tunnel ports on the bridge. And the bridge "br-cap" is controlled by ONOS SDN controller. 13:07:04 To automate the configuration, I introduced a concept of template-based automation . I defined a self-defined template format to describe virtual network topology over multiple servers. 13:07:08 Then my tool automates the configuration of OVS bridges and VXLAN ports via OVSDB protocol, and calls ONOS APIs to down OpenFlow rules to "br-cap" bridges. 13:07:11 As the basic flow rules, we just set broadcast flow rules not fine-grained flow rules. For example, a packet arrives br-cap from br-int, then "br-cap" broadcast the packet to all tunnels. 13:07:39 the picture can not be pasted here 13:09:46 the idea is interesting 13:10:40 the ONOS SDN controller interact with Neutron server via ML2 mechanism driver? 13:11:17 I don't think so 13:11:51 we need to have a meeting to discuss this with Junsik 13:12:25 so one port of the br-cap connects to br-int, the other connects to the br-tun? 13:12:53 i think br-tun is not needed 13:13:05 br-cap does the work 13:13:11 I'll try to find a place to put the pictures sent by Junsik 13:14:01 and during the barcelona summit,when we talked with Kevin about the L2 networking across Neutron, Kevin prefer to rk across Neutron 13:14:36 is it ok for neutron community that we abandon br-tun? 13:15:39 and Kevin prefer to store the vtep in port binding info for push notification 13:15:51 and by the way for external communication 13:16:02 http://lists.openstack.org/pipermail/openstack-dev/2016-November/107061.html 13:18:28 It take times to think over the method for VxLAN l2 networking across Neutron 13:19:31 let's have a meeting at 10:00am (utc 2:00am), I'll provide an etherpad link tomorrow in IRC 13:19:49 ok 13:20:09 #action have a online meeting to discuss VxLAN l2 networking across Neutron 13:20:35 tomorrow? 13:20:42 #info on UTC2:00am Dec 15 13:21:23 #info i.e Beijing time 10:00 am Dec.15, Korea/Japan 11:00 am Dec 15 13:21:45 #info etherpad link will be provided in IRC 13:22:14 #topic Ocata feature development review 13:22:28 let's have a short review on the feature development 13:22:55 please describe shortly and discuss as needed 13:24:36 qos code has completed , i need some time to test in two nodes envir 13:24:48 fix some environment patch and continue to perfect the configuration guide 13:24:51 for lbaas, learn to write lbaas service plugin, and writing spec. 13:24:53 (1) patch to fix resource deletion has got one +2 (2) patch for bridge network combination is still under review, as Joe mentioned (3) a new patch to adpat DVR in cross-pod l3 networking has been submitted (4) start to consider async job reliability improvement 13:24:59 o, xiongqiu, your blueprint and spec also needed 13:25:30 I am doing network and subnet resources update 13:25:30 to Ronghui, good, configuration guide is better and better 13:25:46 releasenote for routing api is delayed for there is a math test this week. and i will deal with it this weekend. 13:26:03 to Zhiyuan, great progress! 13:26:19 to Xiulin, keep going 13:26:40 ok, i will 13:26:47 to Dongfeng, it's ok for release notes, it's not very urgent 13:27:06 ok. 13:27:30 ok 13:27:57 to Yipei, good, for LBaaS, we may need some online discuss, could you organize it? 13:28:07 before you submit the spec 13:28:29 ok 13:29:43 for me, I am claening tables,but when some tables removed,related futures should update. 13:29:53 i will create an etherpad and write down some items to be discussed, when i have a better understanding of lbaas 13:30:34 to Jiawei, which feature needs to update, you mean the az_hint for external network? 13:32:09 yes. 13:32:26 is there any other features need to update? 13:33:08 pod binding api and its doc should be removed,and resource api shoud be changed too 13:33:28 resource routing api shoud be changed too 13:34:01 for pod table, how do you think about to change the pod_name to region_name 13:34:22 I just remove some tables that not need update future 13:34:55 it's ok to clean step by step 13:35:03 with several patches 13:35:18 small patch will get merged sooner 13:35:36 to Dongfeng, yes, these should be update too 13:35:41 so,next week,maybe I will meet some trouble,I am going to ask you in irc 13:35:52 no problem, welcome 13:36:13 for pod_name, I searched the repository, seems 30 places found 13:36:35 could i complete the pod binding api clean part? 13:36:59 of course. :) 13:37:14 including pod binding api clean, it's doc clean, and resource api update. 13:37:34 yes, dongfeng, please 13:37:43 it's open source 13:37:50 colloboration is welcome 13:37:55 fine. i will deal with them later. 13:37:57 it also need some synchronize from tricircle to trio2o and i am working on it 13:38:09 ok, Ronghui 13:38:43 #info smaller patch will get merged sooner 13:39:06 for az_hint, I have one idea 13:39:29 usually az_hint will be put with az name list 13:39:51 but for tricircle, we map az to region 13:40:10 and for external network, input region in az_hint 13:40:42 so when there is need to lookup the az, will search the pod first 13:41:01 and if the az name in the pod table is not matched, 13:41:24 we can search again whether the region_name can be matched 13:41:49 this will bring flexibility to network/router az_hint input 13:41:58 how do you think about this idea? 13:44:07 how about users specify az in the az_hint when creating external network? 13:45:29 first match AZ(it's still one parameter in pod table), if not find try to match pod_name 13:46:08 but we need pod for external network 13:46:29 az may contain more than one pod 13:46:30 if more than one, should we check to see if there is external network in that pod? 13:46:56 zhiyuan's idea sounds easier 13:47:20 but at the beginning no external networks in pods 13:47:22 may be two search function 13:47:43 one find_by_region used for external network creation 13:47:54 the other one find_by_az 13:48:14 in find_by_az, first match with az_name, then try pod_name 13:48:49 I don't understand these code about external network,so I should read them,I can just try your ider after I understand them 13:48:55 to joe 13:49:06 ok, so for external network creation, users still need to specify pod_name, or say region_name 13:50:50 in fact, it's for router/network, the az_hint will be more flexible, you can specify az_name or region_name 13:51:28 for the enduser, specify region will be more intuitive when creating network 13:52:08 Another approach is to add "ready_for_external" network attribute to pod, then if az_name is specified when creating external network, we can filter pods by that attribute 13:52:58 sorry, shoule be "ready_for_external_network" attribute 13:52:59 yes, this way can keep the sematics of az_hint 13:53:28 and users can also use region_name if they like 13:53:49 so we don't have special handle for external network 13:53:59 good proposal 13:54:53 the parameter is too long, a shorter one will be better 13:54:59 :-) 13:55:32 sure 13:56:21 ok, let's have a discussion about L2 network tomorrow 13:56:43 any other topic 13:56:47 maybe a BP? the change is not hard, but many things like code, readme, api document need to be changed 13:56:55 yes 13:57:16 but this update will make the usage more friendly 13:57:35 no for me 13:57:45 no other topic 13:57:48 no 13:57:50 no for me 13:57:52 no for me 13:58:08 no 13:58:19 ok, thank you 13:58:22 #endmeeting