KO
|
EN
gitlite — search
Search
#typescript
#ai-agents
#ai
#dsh-plugin
#deepseek-harness
#open-source
#cli
#claude-code
#codex
#developer-tools
#react
#windows
drbd-reactor
★ 52
Open GitHub ↗
Monitors DRBD resources via plugins.
Download README (.md)
Explore Similar Repositories
blockstor
:
Free Software-Defined Storage System based on Kubernetes
ganeti-rpm
:
Ganeti RPM Packaging
mq-aws
:
Sample code for running IBM® MQ on Amazon Web Services (AWS)
ansible-drbd
:
Ansible role to install/configure DRBD distributed block storage
kube-lustre
:
High-available Lustre filesystem concept with DRBD for Kubernetes.
// repository documentation
Was this content helpful?
★ 0
(0 ratings)
Select Rating:
★
★
★
★
★
Submit Feedback
Recent Feedback
×
Download README
Do you want to download the
README.md
file for
drbd-reactor
?
Download (.md)
# drbd-reactor `drbd-reactor` is a daemon consisting of a core that does DRBD events processing and plugins that can react on changes in a DRBD resource. ## Plugins | Plugin | Purpose | | -------------------------------- | ------------------------------------| | [debugger](/doc/debugger.md) | Demo that prints state changes | | [promoter](/doc/promoter.md) | Simple HA for resources | | [umh](/doc/umh.md) | User mode helper | | [prometheus](/doc/prometheus.md) | Prometheus endpoint | | [agentx](/doc/agentx.md) | AgentX subagent for SNMP monitoring | ### Implementation - [x] debugger - [x] promoter - [x] umh (user defined filters) - [ ] umh (replacement for kernel called helpers: Under active development) - [x] prometheus ## Configuration This daemon is configured via a configuration file. The only command line option allowed is the path to the configuration. The default location for the config is `/etc/drbd-reactor.toml`. The repository contains an example [drbd-reactor.toml](/example/drbd-reactor.toml). This file should act as the entry point only to specify a snippets directory where one places one snippet per plugin instance. Users should use `drbd-reactorctl` to manage these snippets. ### Automatic Reload In very dynamic environments it might be favorable to automatically reload the daemon whenever a configuration snippet is added or removed. This can be done by using the `drbd-reactor-reload` systemd path unit that is shipped in the `example` directory: ```shell cp example/drbd-reactor-reload.{path,service} /etc/systemd/system/ systemctl enable --now drbd-reactor-reload.path ``` ## Building This is a Rust application. If you have a Rust toolchain and `cargo` installed (via distribution packages or [rustup](https://rustup.rs)) you can build it via: ```shell cargo build ``` ## Architecture ### Core The core consists of 2 threads. The first one is responsible for actual `drbdsetup events2` processing. It sends update event structs on a channel to the main thread. The main thread keeps track of the overall DRBD resource state by applying these updates to an internal map of resource structs. Think of these as the output of `drbdsetup status --json`. The second purpose is to generate `PluginUpdate` enums if important properties of a resource changed. For example one variant of the `PluginUpdate` is `ResourceRole`, that is generated if the role of a resource changed. These variants follow the same structure: They contain the event type, information that identifies the actual DRBD object (resource name, peer ID, volume ID,...) and the `old` and `new` states. These old/new states contain the rest of the relevant information within this event (e.g., the `may_promote`, and `promotion_score`). Think of `old` and `new` structs as easy to consume diffs. A `PluginUpdate` also contains the current, complete state of the resource. ### Plugins Plugins are maintained in this repository. Every plugin is started as its own thread by the `core`. Communication is done via channels where plugins only consume information. The core expose a `PluginUpdate` channel, the plugin decides if it wants to use the diffs from `old` and `new`, and/or the complete current state from `resource`. ## Contributions Contributions are obviously always welcome! Please talk to us first *before* you start working on a new plugin. Please check the state of plugins at the beginning of the document, and don't work on plugins that are currently under development by somebody else. ### Dependencies We have to be a bit careful introducing new dependencies as we want to provide `drbd-reactor` via a [PPA](https://launchpad.net/~linbit/+archive/ubuntu/linbit-drbd9-stack). So please use only dependencies that are packaged as `librust-` package in Ubuntu Jammy. We might relax that, but that would need to be a very very convincing argument. Again, talk to us early. ## Current implementation considerations Currently plugins have to filter their `PluginUpdate` stream by themselves. This keeps the core simple, but allowing some kind of filtered subscription could make sense. If we don't do that, and keep the "all plugins get all events" semantic, we could switch to a broadcast channel, there are some crates out there.
