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