01:01:44 <zhiyuan> #startmeeting tricircle
01:01:44 <openstack> Meeting started Wed Sep 13 01:01:44 2017 UTC and is due to finish in 60 minutes.  The chair is zhiyuan. Information about MeetBot at http://wiki.debian.org/MeetBot.
01:01:45 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
01:01:47 <openstack> The meeting name has been set to 'tricircle'
01:02:08 <zhiyuan> one thing to share, screen is removed from DevStack master
01:03:02 <joehuang> hello
01:03:16 <zhiyuan> the USE_SCREEN option will not take effect, we need to use systemd to interact with the services instead
01:03:19 <zhiyuan> hi joe
01:03:25 <RonghUI> yes now we can use systemctl to debug process
01:03:37 <zhiyuan> #link https://docs.openstack.org/devstack/latest/systemd.html
01:03:37 <joehuang> not so convinenet
01:04:16 <zhiyuan> here is link discussing how to use systemd in DevStack, though I like screen better
01:05:10 <RonghUI> It seems that systemd dont support the process switch in one window
01:05:35 <zhiyuan> to debug service, we need to use pdb, stop the systemd unit, then start the service manually
01:05:47 <zhiyuan> or use remote-pdb
01:06:40 <joehuang> we can still start the process manually but not run as service, isn't it?
01:07:21 <zhiyuan> to ronghui, then what will happen if you use journalctl to see the logs of multiple services?
01:07:52 <RonghUI> it is fine to use journalctl to see the log
01:08:17 <zhiyuan> to joe, yes, so you can start a screen and run the services inside the screen
01:08:35 <RonghUI> just like the other commands
01:09:36 <RonghUI> and i think there is no different to use journalctl or vim to see the logs
01:09:47 <zhiyuan> to ronghui, after executing journalctl, if new logs come, can you see that? or you need to issue another journalctl command?
01:10:32 <RonghUI> no it synchronizes
01:10:46 <zhiyuan> good
01:11:33 <zhiyuan> I am still using an old version DevStack so haven't tried the systemd way
01:12:13 <RonghUI> dont change to the newest Devstack verison
01:12:32 <RonghUI> you will regret
01:12:35 <zhiyuan> why?
01:13:09 <zhiyuan> it seems that you are familiar with the systemd way now
01:13:22 <RonghUI> if you want to see different service logs, you need to open different windows
01:14:31 <zhiyuan> ah, or you can start a screen session by yourself
01:14:43 <RonghUI> and if you restart the service, the related information will not display after the restart command
01:14:52 <RonghUI> so you need to see the logs screen
01:15:23 <RonghUI> I feel very troublesome
01:15:58 <zhiyuan> hmm, so during debugging, manually staring the service seems a better way
01:16:28 <zhiyuan> then all the information will be printed to the window
01:17:10 <RonghUI> yes and if so, it is no differents from the general method
01:18:13 <zhiyuan> restarting several services together will be easy using systemd :)
01:18:27 <RonghUI> yes
01:19:21 <zhiyuan> ok, next
01:19:55 <joehuang> the reason to use systemd is to make the development environment being similar like the production environment as much as possible
01:20:42 <zhiyuan> to joe, agree, but I think "Dev"Stack is for development
01:21:52 <zhiyuan> since joe didn't attend the last meeting, I would like to revisit the storyboard migration topic
01:22:13 <zhiyuan> #topic storyboard migration
01:23:13 <zhiyuan> the storyboard team has prepared scripts to automatically migrate all the open bugs
01:23:19 <joehuang> when should the migration be done
01:25:54 <zhiyuan> haven't received a deadline, but the storyboard team hopes we can migrate soon
01:26:07 <joehuang> fine
01:26:34 <zhiyuan> it's said that they have done some tests on the scripts of our project
01:26:52 <joehuang> will the milestone management be migrated too
01:27:16 <zhiyuan> blueprint and closed bugs will not be automatically migrated though
01:27:40 <zhiyuan> the history is kept in launchpad
01:29:28 <joehuang> inconvenient for history tracing
01:30:54 <joehuang> we may discuss the milstone and plan in PTG
01:31:57 <zhiyuan> yes
01:33:35 <zhiyuan> so I reach the storyboard team to start the migration?
01:34:04 <joehuang> ok
01:34:49 <zhiyuan> fine
01:35:07 <zhiyuan> #topic feature progress
01:36:32 <Yipei> lbaas is almost done, i am writing installation and configuration guide for lbaas
01:37:06 <zhiyuan> I tested the qos but still met some problems. The test step: (1) create network/subnet in centralregion (2) boot VM in regionone (3) create qos in centralregion (4) update network with qos (5) async job is triggered but fails
01:38:40 <RonghUI> i also do the same test in qos and find some error in q-svc0 service
01:39:06 <zhiyuan> to yipei, what about the multi-subnet case, let's say subnet1 in region1, subnet2 in region2, lbaas in region1, after you add a member of region2, subnet2 is automatically created in region1?
01:39:57 <Yipei> yes, i tested the code under review
01:40:03 <Yipei> it works
01:40:03 <zhiyuan> to ronghui, so you can debug based on logs. in my test, the expected result is that qos will be created in regionone
01:40:05 <RonghUI> to zhiyuan, what log you saw about async job error
01:40:49 <zhiyuan> it says you try to access a list with string index
01:41:15 <zhiyuan> like rules[rule_type], but rules is a list
01:41:25 <zhiyuan> you treat it as a dict
01:41:33 <Yipei> neutron lbaas only checks whether the subnet exists, when neutron lbaas try getting the subnet, local neutron will create the bottom network as well as subnet
01:42:29 <Yipei> which is implemented in this patch #link https://review.openstack.org/#/c/498407/
01:43:16 <RonghUI> to zhiyuan, not created in RegionOne, QoS created in CentralRegion and if update the port in the CentralRegion, it will synchronize in port of RegionOne
01:44:25 <zhiyuan> so adding a member will attaching a port to amphora, this will trigger our cross-region vxlan networking process, then amphora can reach the member VM, is that correct?
01:44:41 <Yipei> yes, that's right
01:46:28 <zhiyuan> to ronghui, but the qos also need to be created in RegionOne, after that the port in RegionOne can be updated with that qos
01:46:58 <zhiyuan> to yipei, i see
01:47:58 <RonghUI> yes and QoS creating in Region wil happen when update the port, but it failed
01:48:35 <joehuang> Hi, I have to leave for another meeting
01:48:44 <joehuang> sorry leave early
01:48:51 <RonghUI> of Bye
01:49:03 <RonghUI> sorry ok Bye
01:49:12 <zhiyuan> fine, Joe, bye
01:49:53 <Yipei> bye, joe
01:49:59 <zhiyuan> in my network case, the qos rule syncing fail, so I think they are different issues
01:50:20 <zhiyuan> I update the **network** with qos
01:52:57 <RonghUI> ok i will try to fix it
01:53:47 <zhiyuan> you can fix your port case first
01:54:28 <RonghUI> ok
01:54:35 <zhiyuan> #topic open discussion
01:54:44 <zhiyuan> any other topics?
01:54:57 <Yipei> no
01:55:47 <RonghUI> no for me
01:56:40 <zhiyuan> ok, thanks for attending the meeting
01:56:43 <zhiyuan> #endmeeting