13:00:01 #startmeeting senlin 13:00:02 Meeting started Tue Dec 26 13:00:01 2017 UTC and is due to finish in 60 minutes. The chair is ruijie. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:00:04 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:00:06 The meeting name has been set to 'senlin' 13:02:21 hi 13:02:27 hi Qiming 13:02:43 evening 13:05:13 let's get started :) 13:05:17 okay 13:05:29 https://review.openstack.org/#/c/529457/2 13:05:29 patch 529457 - senlin - add endpoints as plugin 13:05:56 I am moving the endpoints classes outside of the HM 13:06:08 hi 13:06:10 yes. saw it 13:06:39 but ... I'm wondering if we really need a separate endpoint-level configuration 13:06:43 hi elynn 13:07:32 em, that is optional, if we want to extend it later :) 13:08:11 I see the advantages 13:08:23 evening elynn boy 13:09:04 evening all \o/ 13:09:09 one problem I am facing is the "project_id" field 13:09:11 http://git.openstack.org/cgit/openstack/senlin/tree/senlin/engine/health_manager.py#n69 13:09:57 as we want to hold one listener for one engine who hold different clusters belong to different projects .. 13:10:55 it is part of filter_rule 13:11:02 shell we make the filter rule coarse grained? 13:11:39 then you may lose all the benefits you are aiming at 13:13:09 say you don't filter events by tenants, your filter rule will get invoked by all compute instance events ... 13:15:07 yes Qiming, that is not good 13:16:35 em, then we need to modify the filter rule dynamically, {"project_id": "[this is a list]"} 13:16:59 :) 13:17:08 you will have to hack oslo.messaging 13:17:14 actually, it may not be that bad 13:17:52 I assume these endpoints will be invoked on a per-event basis 13:18:08 no matter those events come from which tenant/project 13:18:25 the only difference is where irrelevant events are filtered out 13:19:12 it could be done in oslo.messaging code, or it could be done in senlin code 13:19:51 if the senlin provided endpoint is invoked, the only difference is the call stack is a little bit deeper 13:22:29 but we have to provide endpoints when initializing the listener 13:24:11 then we don't filter project_id 13:25:43 we check the ctxt.project in the info() method 13:26:04 have to take care of my girl ... she is not sleeping .... sigh 13:26:18 sure :) 13:35:58 back 13:39:26 we can maintain a list to store the projects 13:39:42 so that we can filter the events ourselves instead of hacking oslo.messaging 13:45:14 that will make the code complicated 13:45:37 you will need locks to manage the project list to watch 13:46:48 em, what context the ctxt is in the info(...), Qiming 13:48:06 it is a callback 13:48:43 oslo.messaging constructs a context instance from the event when before invoking the method 13:53:29 okay, thanks Qiming. 13:54:15 btw, the splitting tempest plugin is not yet completed :( 13:54:35 did't get time to figure that out, may need more time 13:56:10 okay 13:56:57 that's all from my side 14:00:10 okay, thanks for joining, Gentlemen 14:00:17 #endmeeting