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