13:01:53 #startmeeting senlin 13:01:53 Meeting started Tue Nov 14 13:01:53 2017 UTC and is due to finish in 60 minutes. The chair is ruijie_. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:01:54 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:01:56 The meeting name has been set to 'senlin' 13:02:19 evening 13:02:22 hi all, this is the agenda: https://wiki.openstack.org/wiki/Meetings/SenlinAgenda#Agenda_.282017-11-14_1300_UTC.29 13:02:29 hi Qiming 13:05:14 ok, let's get started :) 13:06:22 do we have any summit experience sharing? 13:07:35 well,https://etherpad.openstack.org/p/senlin-11-17 13:08:09 I drafted a etherpad page about the questions we met this week 13:08:20 1. about the health policy 13:08:59 the polling mode should work well 13:09:29 just need to improve to use user defined recovery action 13:09:57 but for the listening mode, we are not able to stop the listener after health policy detached 13:10:20 yes 13:11:34 listener cannot be stopped? 13:11:37 seems like the creation and starting of listener is asynchronous 13:12:02 no Qiming 13:12:40 alright, have to check oslo.messaging for the correct sequence on doing that 13:13:48 http://git.openstack.org/cgit/openstack/senlin/tree/senlin/engine/health_manager.py#n298 13:14:19 yes, that is where we added a thread 13:14:22 the return value is the thread itself, but the thread will be released after start the listener 13:18:05 thread is released? 13:19:51 yes, I've tested it multiple times. 13:21:51 then check the oslo_service.threadgroup for correct usage? 13:22:25 https://github.com/openstack/oslo.service/blob/master/oslo_service/threadgroup.py#L101 in this, will be appear remove error 13:24:26 use code pdb, self.threads get {} 13:27:19 scheduler call self.threads.append-->listener call self.threads.append-->scheduler call self.threads.remove 13:27:46 okay, can we try just call listener.stop() here: senlin/tests/unit/engine/actions/test_action_base.py 13:28:01 or we call listener.stop() first 13:28:59 listener.stop() may invoke the link established by thread group 13:29:13 then thread_done() will be invoked automatically 13:34:58 hi 13:35:19 actually the thread already been released after invoke listener.start() 13:36:24 as I concerned, the logic of 'lister.start()' == threadpool.add(task) 13:37:26 no it cannot be released 13:37:35 read the logic 13:38:38 only a thread link was added 13:43:49 hi, Qiming ,ruijie_ 13:44:02 I was talking about oslo.service side 13:44:07 not oslo.messaging side 13:44:25 the event listening logic was learnt from ceilometer 13:45:28 I cannot recall whether seting executor to 'eventlet' rather than 'threading' would help 13:45:40 you may want to give it a try though 13:50:26 sure, will dig this problem 13:50:47 hi XueFeng 13:51:29 the second one is about how to use user defined action to recover the physical resources 13:52:14 as we discussed, we can let the health policy support node_recover action so that decision will be made when checking health poliy 13:52:39 or we can set the recovery action to HealthRegistry directlly 13:54:04 hi, ruijie_.you are discussing a health policy bug? 13:54:15 yes XueFeng 13:55:17 Which problem? any bug report? 13:55:42 no bug reported yet 13:56:18 the problem now is that: 1. recovery action will recreate the resource by default, 2. we are not able to close/stop the listener after policy detached 13:57:44 there is no conflict ruijie 13:57:55 we should persist the action into db 13:58:14 then retrieve it, send it as part of the recover action 13:58:22 have to leave to join a call 13:58:30 sure 13:59:03 Gentlemen, time's run out 13:59:09 we can discuss it in #senlin 13:59:25 ok 13:59:27 #stopmeeting senlin 13:59:35 #stopmeeting 13:59:43 :( 14:00:02 Its end meeting 14:00:06 :) 14:00:18 #endmeeting