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