fix(vip): make the Adoptable tag name the real blocker (v1.10.11)

The tag and the disabled Adopt button were computed by two separate ladders and
could disagree. Seen on a live pair: one node's keepalived.conf had an
unbalanced brace, so it was excluded from the instance; its partner was then
tagged "MASTER missing" - technically true, because the unreadable node's
state MASTER had not been counted - while the actual reason (the peer cannot be
taken over, so adopting would strand it) sat only in the button's tooltip. The
label pointed the operator at the wrong node.

groupState now makes ONE ordered decision and returns the label, its colour and
the reason together, so the tag can never describe a different condition than
the one disabling the button. A group held up by a node that references the
same address but cannot be adopted with it reads "blocked by peer"; two MASTERs
is distinguished from none.

Display only: the endpoint's checks and refusals are untouched.

Backend suite: 1366 passed, 152 skipped. Frontend build clean.

Author: taylanbakircioglu

README.md

@@ -2474,7 +2474,8 @@ Developed with ❤️ for the HAProxy community
 
 ## Release Notes
 
-- **v1.10.10** (2026-08-14) — **Adoption blockers are listed once per instance**: with the instance-based panel a two-node pair reported the *same* problems about the *same* shared config twice, once per member, and the line numbers differ between the two files so plain de-duplication did not collapse them. Four issues on a pair read as eight, in both the *Adoptable* tooltip and the adopt dialog. They are now merged on the message text with the leading `line N:` ignored, so each distinct problem appears once. Display only: the endpoint already evaluated the combined set and its refusals are unchanged. On the public repo this is the first artifact carrying v1.10.4 through v1.10.9: none was released separately, because VIP adoption did not work end to end until these fixes landed.
+- **v1.10.11** (2026-08-14) — **The *Adoptable* tag names the problem that actually blocks adoption**: the tag and the disabled *Adopt* button were computed separately and could disagree. A pair blocked because its peer's `keepalived.conf` could not be parsed was labelled **MASTER missing** — technically true, since the unreadable node's `state MASTER` had not been counted, but it pointed the operator at the wrong node while the real reason sat in the button's own tooltip. Both now come from one ordered decision, so the label, its colour and the tooltip always describe the condition that stops the adoption; a group held up by an unreadable or unreachable peer reads **blocked by peer**, and two MASTERs is now distinct from none. Display only: what the endpoint accepts or refuses is unchanged. On the public repo this is the first artifact carrying v1.10.4 through v1.10.10: none was released separately, because VIP adoption did not work end to end until these fixes landed.
+- **v1.10.10** (2026-08-14) — **Adoption blockers are listed once per instance**: with the instance-based panel a two-node pair reported the *same* problems about the *same* shared config twice, once per member, and the line numbers differ between the two files so plain de-duplication did not collapse them. Four issues on a pair read as eight, in both the *Adoptable* tooltip and the adopt dialog. They are now merged on the message text with the leading `line N:` ignored, so each distinct problem appears once. Display only: the endpoint already evaluated the combined set and its refusals are unchanged.
 - **v1.10.9** (2026-08-14) — **Adoption refuses to strand a node or silently normalise a peer's settings**: v1.10.8 adopted the whole VRRP instance, but it could only *match* a node it was able to read, that was enabled, and that sat in the same pool. Each of those was a door a real member of the group left through silently — the nodes that remained were rewritten while the one that left kept serving the same address from an unmanaged config. Seen on a live pool: one node of a pair had an unclosed `vrrp_instance` block, so it parsed to nothing while its partner parsed cleanly. Instead of guarding each door, adoption now asks the question directly — is there **any** reported `keepalived.conf` that mentions this virtual address and is not among the nodes being taken over — and refuses naming the node and the reason (unparseable, agent disabled, different pool). Separately, four VIP-level fields (`prefix_length`, unicast/multicast mode, HAProxy tracking and the VRRP password) are stored once and re-rendered onto **every** member, so taking them from whichever node was clicked imposed its settings on the others; the prefix length is the sharpest, because the design refuses to *guess* a netmask for a live VIP and copying one node's netmask onto another is that same change by another name. Adoption now requires the nodes to agree on all four, and compares the VRRP secret by decrypting each node's token (Fernet is non-deterministic, so the ciphertexts cannot be compared). Finally, the takeover authorisation is genuinely one-shot: `takeover_expected_hash` was written at adoption and never cleared, so it stayed valid for that file content indefinitely — it is now retired the moment a member acknowledges our rendered config, gated on the acked hash matching so a failed deploy never drops it. No schema change, no agent change.
 - **v1.10.8** (2026-08-13) — **VIP adoption takes the whole VRRP instance**: adoption used to take only the node whose row was clicked, which broke the exact case the feature exists for, a running HA pair. Adopting the **BACKUP** alone produced a VIP that could never be applied (*exactly one member must be MASTER*); adopting the **MASTER** alone left the peer unmanaged, and adopting it afterwards hit the VRID-collision guard with 409, so the pair could not be completed from the panel at all. Most serious, on a **unicast** instance the single-member render dropped the unicast block entirely — the renderer emits it only when it has peer addresses — so keepalived fell back to **multicast** on the adopted node while its peer stayed unicast: they stop seeing each other and **both** claim the VIP. Adoption now resolves the whole instance, keyed on `(virtual_router_id, virtual address)` exactly as keepalived groups nodes, and every participating node becomes a member with the role, priority and interface its own file declares and its own one-shot takeover hash. It refuses, with the reason, when the group does not have exactly one MASTER, when the nodes disagree on `advert_int`, when a declared unicast peer is not among the nodes being adopted, or when a node already belongs to a live VIP — a rule create/edit enforced and adoption did not. The panel now lists one row per **instance** instead of per node. Two further fixes: the Apply Management **View Change** diff did not recognise the `adopt` action, so it fell through to the generic HAProxy diff and rendered the cluster's entire `haproxy.cfg` as removed; and **rejecting** an adoption hid the node from the panel permanently, because `adopted_vip_id` is write-once, a VIP is only ever soft-deleted (so the column's `ON DELETE SET NULL` never fires) and the agent does not re-report an unchanged file — adoptability is now derived from whether the linked VIP is still active, which self-heals reject, undo-reject and approved teardown alike. No schema change, no agent change.
 - **v1.10.7** (2026-08-13) — **HA / VIP follows the selected cluster**: the page ignored the cluster picker in the header. On a multi-cluster install both the VIP table and the new *Unmanaged keepalived detected* panel listed every cluster's nodes at once and did not change when the selection did, so the panel appeared to be stuck on one cluster's keepalived. Both lists now send `cluster_id`, resolved to that cluster's pool exactly as the Apply Management view already did. The API parameter is **optional**: a caller that omits it still receives the whole fleet, so nothing outside the page changes. This is a deliberate behaviour change for the VIP table, which was fleet-wide before. Backend and frontend only: no schema, no agent change.

UPGRADE_GUIDE.md

@@ -1,3 +1,19 @@
+# Upgrade Notes — v1.10.11 (Adoptable tag names the real blocker)
+
+**Frontend only, no schema change.** No `SCHEMA_VERSION` bump, no API change, no agent change.
+
+- The *Adoptable* tag and the disabled *Adopt* button were derived separately, so they could
+  name different problems. A pair blocked by a peer whose config could not be parsed showed
+  **MASTER missing**, because the unreadable node's `state MASTER` had not been counted — true,
+  but it sent the operator to the wrong node. Both now come from one ordered decision.
+- New label **blocked by peer** for a group held up by a node that references the same address
+  but cannot be taken over with it. Two MASTERs is now distinct from none.
+- Display only. The endpoint's checks and refusals are unchanged.
+
+**Rollback:** safe; purely presentational.
+
+---
+
 # Upgrade Notes — v1.10.10 (Adoption blockers listed once per instance)
 
 **Frontend only, no schema change.** No `SCHEMA_VERSION` bump, no API change, no agent change.

backend/version.json

@@ -1,5 +1,5 @@
 {
-  "version": "1.10.10",
-  "releaseName": "Adoption blockers listed once per instance, not once per node",
+  "version": "1.10.11",
+  "releaseName": "The Adoptable tag names the problem that actually blocks adoption",
   "releaseDate": "2026-08-14"
 }

frontend/package.json

@@ -1,6 +1,6 @@
 {
   "name": "haproxy-openmanager-frontend",
-  "version": "1.10.10",
+  "version": "1.10.11",
   "description": "HAProxy Load Balancer Management UI",
   "license": "AGPL-3.0-or-later",
   "dependencies": {

frontend/src/components/VIPManagement.js

@@ -209,20 +209,42 @@ const VIPManagement = () => {
       ? discoveries.filter((d) => !inGroup.has(d.agent_id)
           && (d.config_preview || '').includes(g.vip.virtual_ip))
       : [];
+    // v1.10.11 — ONE ordered decision drives both the label and the button, because they used to
+    // be computed separately and disagreed: a group blocked by an unreadable peer was tagged
+    // "MASTER missing" (its peer's MASTER simply had not been counted) while the disabled button
+    // gave the real reason in its own tooltip. Whatever stops adoption is what the label says.
     let reason = null;
-    if (parseFailed.length) reason = `${parseFailed.map((m) => m.discovery.agent_name).join(', ')}: config could not be parsed`;
-    else if (noCandidate.length) reason = 'no vrrp_instance in the report';
-    else if (strandedPeers.length) {
-      reason = `${strandedPeers.map((d) => d.agent_name).join(', ')} reference ${g.vip.virtual_ip} `
-        + 'but their config could not be parsed — fix those nodes first, or they would be left '
-        + 'running an unmanaged config';
-    } else if (hard.length) reason = hard.join(' · ');
-    else if (masters !== 1) {
+    let label = null;
+    let colour = null;
+    if (parseFailed.length) {
+      reason = `${parseFailed.map((m) => m.discovery.agent_name).join(', ')}: config could not be parsed`;
+      label = 'unparseable'; colour = 'red';
+    } else if (noCandidate.length) {
+      reason = 'no vrrp_instance in the report';
+      label = 'no vrrp_instance'; colour = undefined;
+    } else if (strandedPeers.length) {
+      const names = strandedPeers.map((d) => d.agent_name).join(', ');
+      const why = strandedPeers.every((d) => d.parse_error)
+        ? 'their config could not be parsed'
+        : 'they cannot be taken over with this instance';
+      reason = `${names} also reference ${g.vip.virtual_ip} but ${why} — fix those nodes first, or `
+        + 'they would be left running an unmanaged config on the same address';
+      label = 'blocked by peer'; colour = 'red';
+    } else if (hard.length) {
+      reason = hard.join(' · ');
+      label = `${hard.length} blocker(s)`; colour = 'red';
+    } else if (masters !== 1) {
       reason = masters === 0
         ? 'no node in this instance declares state MASTER — enable the missing node\'s agent so it reports its config'
         : `${masters} nodes declare MASTER; exactly one must`;
+      label = masters === 0 ? 'MASTER missing' : 'two MASTERs'; colour = 'red';
+    } else if (blockers.length) {
+      label = 'needs review'; colour = 'gold';          // resolvable in the adopt dialog
+    } else {
+      label = 'yes'; colour = 'green';
     }
-    return { parseFailed, noCandidate, hard, loss, prefix, masters, blockers, reason };
+    return { parseFailed, noCandidate, hard, loss, prefix, masters, blockers,
+             strandedPeers, reason, label, colour };
   };
 
   const openAdopt = (group) => {
@@ -646,24 +668,15 @@ const VIPManagement = () => {
                 ) },
               { title: 'Adoptable', key: 'adoptable',
                 render: (_v, r) => {
+                  // Label, colour and tooltip all come from the single ordered decision in
+                  // groupState, so the tag can never name a different problem than the one that
+                  // actually disables the button.
                   const st = groupState(r);
-                  if (st.parseFailed.length) {
-                    return (
-                      <Tooltip title={st.parseFailed.map((m) => `${m.discovery.agent_name}: ${m.discovery.parse_error}`).join(' · ')}>
-                        <Tag color="red">unparseable</Tag>
-                      </Tooltip>
-                    );
-                  }
-                  if (st.noCandidate.length) return <Tag>no vrrp_instance</Tag>;
-                  if (st.hard.length || st.masters !== 1) {
-                    return <Tooltip title={st.reason}><Tag color="red">
-                      {st.hard.length ? `${st.hard.length} blocker(s)` : 'MASTER missing'}
-                    </Tag></Tooltip>;
-                  }
-                  if (!st.blockers.length) return <Tag color="green">yes</Tag>;
-                  return (
-                    <Tooltip title={st.blockers.join(' · ')}><Tag color="gold">needs review</Tag></Tooltip>
-                  );
+                  const detail = st.parseFailed.length
+                    ? st.parseFailed.map((m) => `${m.discovery.agent_name}: ${m.discovery.parse_error}`).join(' · ')
+                    : (st.reason || st.blockers.join(' · '));
+                  const tag = <Tag color={st.colour}>{st.label}</Tag>;
+                  return detail ? <Tooltip title={detail}>{tag}</Tooltip> : tag;
                 } },
               { title: 'Actions', key: 'actions',
                 render: (_v, r) => {