metabase.metabot.instance
Logic for deciding which Metabase instance in a multi-instance (i.e., horizontally scaled) setup gets to be the MetaBot.
Close your eyes, and imagine a scenario: someone is running multiple Metabase instances in a horizontal cluster.
Good for them, but how do we make sure one, and only one, of those instances, replies to incoming MetaBot commands?
It would certainly be too much if someone ran, say, 4 instances, and typing metabot kanye into Slack gave them 4
Kanye West quotes, wouldn't it?
Luckily, we have an "elegant" solution: we'll use the Settings framework to keep track of which instance is currently serving as the MetaBot. We'll have that instance periodically check in; if it doesn't check in for some timeout interval, we'll consider the job of MetaBot up for grabs. Each instance will periodically check if the MetaBot job is open, and, if so, whoever discovers it first will take it.
How do we uniquiely identify each instance?
local-process-uuid is randomly-generated upon launch and used to identify this specific Metabase instance during
this specifc run. Restarting the server will change this UUID, and each server in a hortizontal cluster will have
its own ID, making this different from the site-uuid Setting. The local process UUID is used to differentiate
different horizontally clustered MB instances so we can determine which of them will handle MetaBot duties.
TODO - if we ever want to use this elsewhere, we need to move it to metabase.config or somewhere else central like
that.
Logic for deciding which Metabase instance in a multi-instance (i.e., horizontally scaled) setup gets to be the MetaBot. Close your eyes, and imagine a scenario: someone is running multiple Metabase instances in a horizontal cluster. Good for them, but how do we make sure one, and only one, of those instances, replies to incoming MetaBot commands? It would certainly be too much if someone ran, say, 4 instances, and typing `metabot kanye` into Slack gave them 4 Kanye West quotes, wouldn't it? Luckily, we have an "elegant" solution: we'll use the Settings framework to keep track of which instance is currently serving as the MetaBot. We'll have that instance periodically check in; if it doesn't check in for some timeout interval, we'll consider the job of MetaBot up for grabs. Each instance will periodically check if the MetaBot job is open, and, if so, whoever discovers it first will take it. How do we uniquiely identify each instance? `local-process-uuid` is randomly-generated upon launch and used to identify this specific Metabase instance during this specifc run. Restarting the server will change this UUID, and each server in a hortizontal cluster will have its own ID, making this different from the `site-uuid` Setting. The local process UUID is used to differentiate different horizontally clustered MB instances so we can determine which of them will handle MetaBot duties. TODO - if we ever want to use this elsewhere, we need to move it to `metabase.config` or somewhere else central like that.
am-i-the-metabot?clj
(am-i-the-metabot?)Does this instance currently have the MetaBot job? (Does not require any DB calls, so may safely be called often (i.e. in the websocket monitor thread loop.)
Does this instance currently have the MetaBot job? (Does not require any DB calls, so may safely be called often (i.e. in the websocket monitor thread loop.)
start-instance-monitor!clj
(start-instance-monitor!)Start the thread that will monitor whether this Metabase instance should become, or cease being, the instance that handles MetaBot functionality.
Start the thread that will monitor whether this Metabase instance should become, or cease being, the instance that handles MetaBot functionality.
cljdoc is a website building & hosting documentation for Clojure/Script libraries
× close