fix(octavia): carry lb-mgmt state across a roll and target the real health-manager nodes

[traviswu-bigstack]

What type of PR is this?

/kind bug

What this PR does / why we need it

Two octavia per-node config defects found by QA on the 3c2p testbed while verifying #1322
against CUBE_3.1.10_20260903-1323_66cd48a. Both are the same shape — a cluster-discovered value
that the commit path must never author — and they touch the same code.

1. A firmware roll blanks both lb-mgmt ids (#1496). octavia.conf is not in the module's
migrate set, and the shipped file does not contain the two keys at all. A roll boots a freshly
installed slot, so Init() loads that file into oldCfg and the carry-forward added by #1302
copies an empty string. It behaves exactly as written; on a rolled slot there is nothing to carry
forward. This is role-independent, which is why a compute node was hit — something the original
InitCheck() defect could not explain.

Not a regression from #1302. The pre-#1302 gate was if (s_bInit) carry-forward; else blank,
and since Configs is a nested std::map, oldCfg[...] default-constructs "" on a rolled slot —
so both branches produced empty there too. What #1302 changed is observability: before it,
non-master control nodes were blanked by every commit and had no known-good baseline to compare a
roll against.

Fixed with CONFIG_MIGRATE(octavia, CONF). Init() rebuilds cfg from the .def on every
commit and reads the current octavia.conf only as oldCfg, so migrating it feeds the existing
carry-forward and nothing else: the first bootstrap on the rolled slot rewrites the file from the
new release's .def, so no stale keys survive across releases. MainMigrate runs the new slot's
binary against the previous root, so the upgrade that delivers this fix is covered too.

2. controller_ip_port_list named the wrong nodes (#1497). The list was built from
cubesys.control.addrs, but CommitService starts octavia-health-manager under
if (IsCompute(...)). On the testbed all five nodes carried
10.254.0.11/.12/.13:5555 while the only health managers were on p4 (.14) and p5 (.15) —
amphora_health had 0 rows and no failover could ever trigger. #1302's defect-3 fix corrected the
cardinality of this list but not its source set. Invisible on converged 1cc/3cc, where control and
compute are the same machines.

Derived from the nodes that actually run a health manager instead, via cubectl's node list
(backed by /etc/settings.cluster.json, which config_cluster already migrates, so it resolves on
a rolled slot), keeping the current value when it cannot be read.

Which issue(s) this PR fixes

Fixes #1496
Fixes #1497

Special notes for your reviewer

Health repair is deliberately not the fix for #1496. sdk_health.sh:136 gates auto_repair on
! is_cluster_rolling — repair is off for the whole window in which the defect is created — and
both it and the end-of-roll cluster check_repair (proj_functions:1296) are gated on
cube_repair_optout, whose purpose is to keep faults visible. The existing ERR_CODE=10 check
stays exactly as it is, as a net.

UpdateCfg's first parameter is s_lbHa (the amphora topology), not cluster HA. The endpoint
list must not be keyed off it — that was #1322 defect 3 — so ControllerIpPortList no longer
takes an HA flag at all.

QA note: migration carries forward whatever the previous slot has. A node already blanked by
an earlier roll on current firmware stays blank; re-stamp it (hex_config reconfig_octavia or
cluster check_repair) before rolling to a build with this fix.

Upgrade note: controller_ip_port_list is delivered to an amphora at build time, so existing
load balancers need openstack loadbalancer failover to pick up the corrected list.

Verified: hex_config links clean under the project's -Wall -Werror in a fresh jail build dir;
os_octavia_hm_nodes checked against the live 3c2p cluster, where it returns
10.32.36.4,10.32.36.5 → 10.254.0.14:5555, 10.254.0.15:5555, matching the actual
octavia-hm0 addresses. Not yet exercised through a real roll — that is the QA verification in
both issues.

Additional documentation

kb/cubecos/known-issues/octavia-lb-mgmt-ids-lost-on-firmware-roll.md
kb/cubecos/known-issues/octavia-health-manager-endpoint-list-wrong-nodes.md

🤖 Generated with Claude Code