13:01:54 #startmeeting tricircle 13:01:55 hi 13:01:55 Meeting started Wed Jan 11 13:01:54 2017 UTC and is due to finish in 60 minutes. The chair is joehuang. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:01:56 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:01:58 The meeting name has been set to 'tricircle' 13:02:09 #topic rollcall 13:02:14 #info joehuang 13:02:16 #info zhiyuan 13:02:18 #info ronghui 13:02:22 #info dongfeng 13:02:25 #info xiulin 13:02:33 #info fanyishi 13:02:37 #info Yipei 13:02:44 #info WuCheng 13:04:01 #topic Ocata release preparation 13:04:28 hello, as planned, Ocata branch will be created on Jan.24 13:04:50 Is there any challenge for your patches to be merged 13:05:17 not for tricircle but for trio2o 13:05:35 the implementation of xjob enhancement can be submitted tomorrow 13:05:56 share_vxlan is hard to catch the deadline 13:06:25 thank you zhiyuan, the reliability is very important feature to be merged 13:06:39 to Ronghui, Trio2o will not follow the schedule 13:06:50 and no release plan for trio2o yet 13:07:59 https://review.openstack.org/#/c/409040/ is hard to merge and want some help 13:11:00 yes, if you want to make trio2o pass the gate test, the plugin.sh should be enhanced. I'll try to find time to help you 13:11:16 any other chanllenge? 13:11:25 i think the tempest plugin also needs modification 13:11:26 for tricircle features 13:11:30 thank you so much :) 13:11:56 hi there. were can I found the channel of the taas meeting? 13:12:11 sorry, don't know 13:12:34 you may search taas meeting from google 13:13:52 hello 13:13:54 I did. But I only able to find https://wiki.openstack.org/wiki/Meetings/taas 13:14:02 no specific channel 13:14:03 please review the patches for devstack plugin.sh for tricircle too, I have several patches in queue 13:14:44 ok, will review tomorrw 13:14:49 s/tomorrw/tomorrow 13:15:05 to qwebirc50747, sorry, no idea 13:15:55 for vxlan networking, I think we need to plan a release after Ocata release, 13:16:18 hi, you can get the info in this page : http://eavesdrop.openstack.org/ 13:16:20 so we can work hard for vxlan networking in the master branch at the same time 13:16:44 #topic shadow_agent for VxLAN L2 networking/L3 DVR issue 13:17:01 hello, zhiyuan, do you have some progress to share on this feature 13:17:26 for the tricircle ,1) i will try to clean remaining code of nova and cinder 2) the patch for remove codes got +2. 3) After the Qos spec patch merge, will submit the related codes ASAP 13:17:30 Thanks 13:17:53 to Ronghui, thanks, great helpful 13:18:23 yes, for external network, we can also use shadow agent/port to sync the tunnel information, creation of gateway port will also trigger l2 pop 13:19:02 so we just create shadow port for gateway port in each pod 13:19:25 shadow mac not tested yet 13:19:43 shadow mac for DVR not tested yet 13:19:55 that means shade_agent will work for for L2/L3 networking via VxLAN 13:20:07 it's not so urgent 13:20:33 we can begin to work on the spec and code based on this idea 13:21:10 shadow mac for DVR, I think it should be ok too 13:21:14 yes, but i also find that l3 ha can not work properly with l2 pop, not sure if it's a bug or there's something wrong with my environment 13:22:31 with l2 pop, the tunnel between compute host and network host is not created, but if i turn off l2 pop, the tunnel can be created 13:23:24 further investigation could be done in parallel, this is quite strange. maybe L3HA only work for centralized router, not for DVR? 13:23:58 but in my test, the router i created is centrailized, not DVR router 13:24:23 how about DVR router for L3HA? 13:24:36 centralized mode is called "legacy" 13:24:57 the combination of DVR and HA not tested yet 13:25:47 i think DVR is one kind of HA 13:26:09 it seems HA is for DVR 13:26:15 #link https://wiki.openstack.org/wiki/Neutron/DVR/ServiceNode-HA 13:28:25 #info shade_agent works for L3 networking (vxlan as bridge network) too 13:28:25 both of them are implemented in Juno, i think they can work separately 13:29:07 #info L3HA has some issue with L2pop, need more investigation, but not so urgent 13:29:45 #topic shared_vlan confusion when creating vlan network in some specified region 13:30:08 hello, I am writing the user guide for different scenario 13:30:20 good 13:30:35 and I found one issue for shared_vlan concept 13:31:00 if we want to create a network which only resides in one region and the network type is vlan 13:31:33 then we have to specify the physical network type as shared_vlan 13:32:08 otherwise no other way to create a vlan network in local Neutron 13:32:35 by default, the local network in central Neutron means the network type is decided by local neutron 13:32:54 it could be vlan, vxlan or gre or else, it's undetermined 13:33:31 but shared_vlan, the concept is to create a network spanning into multiple openstack 13:33:44 with same vlan segment 13:34:04 this afternoon 13:34:09 I discussed with zhiyuan 13:34:12 about it 13:35:12 one idea is just use vlan as the physical network type, and using availability_zone_hints to limit where the network will reside 13:36:18 for example, network( physical network type = vlan, az_hint=az1,az2) means the network could be presented in az1 and az2 13:37:07 if only one az is specified, then the network will be limited to one openstack, for example network( physical network type = vlan, az_hint=az1) 13:37:32 if no az_hint is specified, then means the network could be spread into any openstack 13:38:30 no matter the network spread in which az and the physical network type need to be vlan? 13:39:02 if you create a vlan network 13:39:44 the physical network type is not must to be vlan, it could be vxlan too, but currently only shared_vlan supported 13:40:00 this idea is already described in the spec: https://github.com/openstack/tricircle/blob/master/specs/newton/cross-pod-l2-networking.rst 13:40:18 got it 13:40:21 in this section: A Cross Pod L2 Networking Creation 13:43:16 how do you think about to update the shared_vlan to vlan, just use az_hint to limit the scope of the network ? 13:44:35 i think it's fine, two questions (1) do we need to keep local network type (2) how about vxlan network type since shared_vxlan is not supported yet 13:45:06 same question for (2) 13:46:28 1) for local network, we can keep it there for the case where no parameter will be specified creating a network 13:47:08 2) for shared_vxlan, I think we can deal with it as vlan network 13:47:43 just use vxlan for shared_vxlan 13:48:36 then how about user creates a vxlan network with more than one az in az_hint? 13:49:11 then this vxlan network could be spread into these azs 13:49:50 i know, but currently cross pod vxlan network is not supported 13:50:29 just raise exception, not supported yet 13:50:43 ok 13:50:49 no need 13:50:53 one second 13:51:03 in some scenario, for example SDN controller 13:51:17 they can talk with each other via BGP 13:51:48 for just create vxlan network at the bottom region as usual, 13:52:25 we need to add one indicator 13:52:51 if it's by L2pop, shadow_agent, it's not supported 13:53:12 if it's done by SDN controller, then it's ok, just like what vlan has done 13:53:38 discuss this in our release notes? 13:53:51 fine 13:54:14 great 13:54:42 shared_vlan needs to be updated ASAP, before Jan 24 13:54:58 who can help this? 13:55:58 me 13:56:17 i will do it ASSP 13:56:35 ok, thank you xiulin 13:57:10 #action network type "shared_vlan" should be simplified to vlan 13:57:22 you are welcome 13:57:35 #topic open discussion 13:57:42 any other topic 13:57:47 no 13:57:59 no 13:58:03 no 13:58:17 no 13:58:39 ok, thank you very much 13:58:44 #endmeeting