Corosync configuration ownership only belongs to Puppet when the cluster’s membership, quorum votes, and QDevice setup are frozen for the life of the deployment. The instant an operator runs a native join, leave, or vote change, a Puppet-enforced corosync.conf and the cluster’s live state start competing for the same file.
That competition is not a theoretical edge case. Proxmox VE’s pvecm and SUSE Linux Enterprise High Availability’s crm/YaST tooling both treat corosync.conf as something they generate and rewrite as cluster membership changes, not as a static artifact an external config manager should template.
What Corosync Configuration Ownership Means in Practice
On Proxmox VE, pvecm create generates a new cluster configuration, and pvecm addnode or pvecm delnode edit that same file to add or remove a node, each carrying its own node ID and vote count.
The tool also owns quorum-adjacent settings: pvecm expected changes the expected votes value at runtime, and pvecm qdevice setup adds an external QDevice arbiter directly into the live configuration.
SUSE takes the same approach from the other side of the stack. The YaST cluster module and the crm cluster init bootstrap script write the communication channels, authentication settings, and quorum arbitration config, then use Csync2 to push that file to every node.
Configuring QDevice and QNetd after the fact does not require a separate manual edit either — SUSE’s own guidance frames it as an operation performed through the existing cluster tooling, not through a file the administrator hand-maintains.
Why pvecm and crm Already Own the Live File
The reason this matters for Puppet specifically is architectural, not political. Puppet Agent applies a catalog compiled from manifests and Hiera data on a fixed cycle — by default every 30 minutes — and enforces the file state it was told to enforce, regardless of what pvecm or crm wrote in between runs.
If Puppet’s catalog defines a static corosync.conf and a node then joins or leaves the cluster through pvecm, the next Puppet run has no way to know that the on-disk change was legitimate cluster activity rather than manual drift, and either reverts it or reports a spurious inconsistency.
This is a reasonable inference, not something either vendor documents directly. The evidence shows pvecm and crm rewrite corosync.conf as membership changes, and that Puppet enforces whatever state its catalog specifies — but no cited source discusses the two interacting.
What the evidence does not establish is whether Puppet’s type system or a carefully written idempotent module could detect and preserve cluster-tool-owned sections of the file. That is a real gap for anyone planning to templatize corosync.conf.
Where Puppet Fits Around the Cluster, Not Inside It
The safer division of labor, based on what each side of the stack already owns, is to let Puppet manage the layer beneath the cluster and leave corosync.conf itself to the native tool. Puppet can install Corosync packages, open the required UDP ports for cluster traffic, and stage the QNetd host before pvecm or crm ever runs.
Corosync’s own requirements support that split cleanly. Nodes need reachable UDP ports 5405-5412 for corosync traffic and an SSH tunnel on TCP port 22 between nodes, both ordinary host-provisioning concerns that a configuration manager handles well without touching quorum state.
A dedicated QNetd arbitrator is also a good Puppet target, since SUSE recommends placing it on separate hardware from the cluster nodes entirely, on a different network, rack, and power supply than Corosync’s own communication channels.
Puppet Server’s own operational model reinforces staying at the infrastructure layer: it compiles catalogs centrally and listens on port 8140/tcp, a pattern suited to package, service, and firewall management rather than live quorum arithmetic.
What to Verify Before Combining Puppet and Corosync
Before letting Puppet touch corosync.conf, confirm how vote and node-ID logic behaves at the target scale. Proxmox documents production clusters with over 50 nodes, reliable HA quorum requiring at least three nodes, and a token timeout coefficient that defaults to 125 in pvecm create.
For clusters with an even node count, verify whether QDevice’s fifty-fifty split or last-man-standing algorithm is the intended quorum model, since that choice changes what a Puppet-managed provisioning step needs to stage on the QNetd host beforehand.
Also verify Puppet Agent’s check-in interval against how often cluster membership actually changes in the target environment. A 30-minute enforcement cycle is a mismatch if pvecm or crm operations happen more frequently, since Puppet could re-apply stale state mid-change.
Finally, treat any corosync.conf managed jointly by Puppet and a cluster tool as unverified until tested with a real node add-and-remove cycle. None of the cited documentation covers that interaction, and the failure mode — a reverted vote count or node ID — only shows up under a live membership change.
Neither the Proxmox nor the SUSE documentation used here discusses migrating running workloads between separately managed clusters, a related but distinct operation that depends on the source and destination clusters already being stable and independently quorate.