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