Displayed weights are not reflecting the correct values

[jgruberf5]

Problem

F5 BNK > Gateway Topology > expand listener >

Displayed weights are not reflecting the correct values

using v3.0.1 staging branch

Expected behavior

Displayed weights reflect the values that analyzer pod has determined based on its calculations

Actual behavior

weights look to be getting values from somewhere else

Local investigation findings

Actual weights from the following command output:

f5-test@gh200-01:/bnk-config/vlm-front-gw$ kubectl get -n dynamo-system l4route l4route-vlm-internal-gw1 -o jsonpath='{.metadata.annotations.k8s.f5.com/service-settings}'
{"p-vlm-vllm-agg-vlmfrontend":{"10.244.139.205":1},"vlm-vllm-agg-vlmfrontend":{"10.244.123.12":99}}f5-test@gh200-01:/bnk-config/vlm-front-gw$

f5-test@gh200-01:/bnk-config/vlm-front-gw$ kubectl get -n dynamo-system l4route l4route-vlm-internal-gw2 -o jsonpath='{.metadata.annotations.k8s.f5.com/service-settings}'
{"p-vlm-vllm-agg-vlmfrontend":{"10.244.139.205":99},"vlm-vllm-agg-vlmfrontend":{"10.244.123.12":1}}f5-test@gh200-01:/bnk-config/vlm-front-gw$

Suggested fix

---

_{Migrated from sp-prod-field/bnk-forge #37 (opened 2026-04-16; original labels: none). That repository is archived and read-only.
Bare #NNN references in the text above refer to issues and PRs in the original repository, not to numbering here.}

[jgruberf5]

Status: root cause confirmed, on-screen fix blocked on a cluster sample.

The displayed weight comes from spec.rules[].backendRefs[].weight (declared intent), while the analyzer's computed weights live in the k8s.f5.com/service-settings annotation — confirmed. PR #172 was opened to surface that annotation, but review (thanks @mwiget) established that the annotation's semantics can't be settled from the single-backend reporter sample:

• the top-level key is a pool, not necessarily a Service (so a naive per-backend attribution silently no-ops in production);
• the per-pod weights may be a within-pool distribution (summing to ~100) rather than a between-service share;
• F5AIAnalyzerViewer already reads this same annotation as pool-keyed percentages, and the two readers must agree.

PR #172 has been reduced to faithful groundwork (parse the annotation tolerantly, surface it on the route as serviceSettings, aligned with the existing consumer) and converted to draft. It does not change the displayed weight, so this issue stays open.

To finish this: dump kubectl get l4route -n dynamo-system -o json (or the equivalent) from a route with two or more weighted backends across multiple pods. That one sample answers pool→service mapping, within-pool vs between-service semantics, and numeric type at once — and then the topology/backends views can show a correct number.