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