description: This snap includes ha_cluster_exporter to provide Pacemaker-based HA cluster statistics via Prometheus. The exporter inspects the local node on each scrape and exposes metrics for Pacemaker, Corosync, SBD, and DRBD when those components are available.
upstream-relation: I am the publisher packaging this snap (via Canonical) for the open-source upstream project.
supported-category: system monitoring/cluster management.
reasoning: The ha_cluster_exporter acts as a proxy for querying the host’s high-availability cluster state. To do this, it dynamically invokes several system-level administration tools directly, including /usr/sbin/crm_mon, /usr/sbin/corosync-cfgtool, /usr/sbin/sbd, and /sbin/drbdsetup. While we tested bundling these binaries under strict confinement, we encountered two blockers:
Host IPC/Socket Communication: The bundled CLI tools (like crm_mon and corosync-cfgtool) must communicate with the host’s running Pacemaker and Corosync daemons via dynamic IPC Unix sockets (e.g., /var/run/crm/, /var/run/corosync/, etc.). AppArmor strictly denies this access, and hardcoding system-files plugs for every possible cluster socket path is fragile.
Version Skew: Bundling the cluster tools inside the snap creates a dangerous version mismatch between the snap’s client binaries and the host’s server daemons. Cluster communication protocols often require the CLI tool and the running daemon to be on the same version. Classic confinement allows the exporter to invoke the host’s native tools directly, ensuring version parity and allowing IPC communication with the underlying cluster daemons.
Shared Memory Access (/dev/shm/): Pacemaker and Corosync rely heavily on shared memory (/dev/shm/) to store and communicate cluster state. The exporter (and the tools it invokes) requires broad access to this data to function. There is no existing snap interface that allows a confined snap to read the entirety of /dev/shm/. Existing interfaces require specifying exact, predictable paths or are restricted to snap-specific folders, which is incompatible with the dynamic nature of the host’s cluster shared memory.
I understand that strict confinement is generally preferred over classic.
I’ve tried the existing interfaces to make the snap to work under strict confinement.
Could you clarify if hacluster-exporter could fall under the HPC or orchestration category instead? If so, could you explain how it fits that description?
Yes, hacluster-exporter fits into the HPC or orchestration category.
The underlying systems this snap monitors - Pacemaker, Corosync, and DRBD - are the orchestration engines for High-Availability (HA) Linux clusters.
To monitor this orchestration layer, hacluster-exporter must natively interrogate the host’s active orchestration daemons. It does this by executing the host’s own orchestration CLI tools (such as crm_mon and corosync-cfgtool) and reading the dynamic cluster state directly from shared memory (/dev/shm/). This mandatory integration with the host’s orchestration stack is why classic confinement is required.
HPC or orchestration agents/software for running workloads on systems without traditional users where the systems are otherwise managed outside of the agent (ie, the software simply orchestrates running workloads on systems and doesn’t manage the systems themselves). Note: many HPC/orchestration applications can run with strict confinement and classic should only be granted if snapd does not support the specific use case (eg, the need for user accounting).
As per the information available in this thread, I’m not sure that hacluster-exporter simply orchestrates running workloads.
Whilst the technical reasons look plausible to me, we will need an architect override before we can proceed with this request. @pedronis could you please take a look?
@pedronis The components are not packaged with the exporter. The exporter uses the binaries on the host to collect metrics, which is why it is hard to package it as a confined snap.
I believe that in typical setups, Pacemaker, Corosync, SBD, and DRBD are not packaged as a single monolithic bundle. Instead, they are modular, deeply integrated system-level components installed directly onto the host OS via APT or other package managers.
There is no single “default solution” or pre-packaged bundle. Because HA architectures vary wildly, the ecosystem is strictly modular. However, major Linux distributions curate and validate these individual packages together via official repositories, such as the Ubuntu High Availability repository and the RHEL High Availability Add-On. Administrators install only the specific combination of daemons their cluster design requires.
I think I need a bit more context, what is the motivation for packaging ha_cluster_exporter as a snap if much of the rest of the setup is not packaged that way?
@pedronis So it can be used in a charm like generic-exporter-operator to expose and provide metrics to the COS stack. The snap will primarily be used in private clouds and will provide additional observability for the managed systems.
I think we should allow for this one under HPC or orchestration. There are two angles to that:
it is a component of such a solution
it has one of properties of that category which is, it is not really expected or make sense for a user to be tempted to install this on their, let’s say, desktop machine