Request of the `classic` confinement for `hacluster-exporter`

store-requests classic-confinement
1
  • name: hacluster-exporter
  • 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.
  • snapcraft: GitHub - canonical/hacluster-exporter-snap: Snap package for HA Cluster exporter · GitHub
  • upstream: GitHub - ClusterLabs/ha_cluster_exporter: Prometheus exporter for Pacemaker based Linux HA clusters · GitHub
  • 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:
    1. 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.
    2. 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.
    3. 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.

2

This request has been added to the queue for review by the @reviewers team.

3

Hello @deezzir,

The category system monitoring / cluster management is not in our supported list for classic confinement ( Process for reviewing classic confinement snaps ).

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?

4

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.