Fix/voltctl api port forward - #9
Open
serkantul wants to merge 4 commits into
Open
Conversation
…ags to voltha-infra The sanity suite fails at Suite Setup on every target with "VOLTCTL and KUBECTL not configured. Please configure before executing tests." Three harness bugs, none of them in VOLTHA itself: 1. The port-forward block forwards Kafka and the BBSim DMI port but never the VOLTHA API, so every voltctl call gets "dial tcp 127.0.0.1:55555: connect: connection refused". Nothing in the pipeline creates a voltctl config either. 2. $HOME is empty when "Setup environment" writes $GITHUB_ENV, so KUBECONFIG becomes /.kube/... and VOLTCONFIG becomes /.volt/config. Visible as "Config not found: /.kube/kind-kind-ci" in the Install Helm step and "Unable to discover the user's home directory" from voltctl. 3. The onos-classic.onosSshPort / onosApiPort / onosOfPort / individualOpenFlowNodePorts flags are applied to voltha-stack, but onos-classic is a dependency of voltha-infra. On the stack they are silently ignored, onos-classic/templates/nodeports.yaml never renders, and nothing listens on the 30115/30120 the robot args specify. Verified on a kind cluster: the onos-api and onos-ssh NodePort services are now created, voltctl connects, and the ATT sanity suite runs through OLT validation, ONU activation, subscriber-access and EAPOL flow checks. It now fails later, at "Verify Meters in ONOS", on a ConcurrentModificationException in OltMeterService.deleteMeter (ONOS org.opencord.olt 5.2.6) - a separate bug that these fixes make visible. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01XZ6zehezd23CktrW8jdcLN Signed-off-by: serkantul <serkant@gmail.com>
Follow-up to the voltctl/API fix, from a full CI run on a branch. With voltctl
working the suite got 13 minutes into each target and exposed two more harness
bugs:
1. The robot suite reaches ONOS at localhost:30115 (ssh) and :30120 (REST), but
the kind cluster this action creates declares no extraPortMappings, so
NodePort services are never published to the runner:
ssh: connect to host 127.0.0.1 port 30115: Connection refused
HTTPConnection(host='127.0.0.1', port=30120): Connection refused
Forward both explicitly, matching how Kafka and the BBSim DMI port are
already handled.
2. tests/data/bbsim-kind{,-dt,-tt}.yaml have expected serial BBSIM_OLT_10 since
VOL-3634 (2020) for kind-voltha multi-stack numbering, but the loop deploys
olt_id starting at 0, producing BBSIM_OLT_0. Every run burned 9 minutes in
Validate OLT Device failed after retrying for 9 minutes.
No match found for BBSIM_OLT_10 to validate device
Offset the id by 10; the release name stays bbsim${i}.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XZ6zehezd23CktrW8jdcLN
Signed-off-by: serkantul <serkant@gmail.com>
The Jenkins voltha-2.x pipeline always installed voltha-infra with
`-f examples/${workflow}-values.yaml` from voltha-helm-charts. That flag
was not carried over in the migration to GitHub Actions, so ONOS and
bbsim-sadis-server come up on chart defaults for every workflow.
For att the file's only override is:
onos-classic:
config:
componentConfig:
"org.opencord.olt.impl.OltMeterService": '{"deleteMeters": "false"}'
Without it deleteMeters stays true. The olt app's meter reference count
is populated from the device's OpenFlow meter-stats reply, and VOLTHA
does not report one, so every meter sits at referenceCount=0 from the
moment it is created. After zeroReferenceMeterCount (3) polls the app
logs "Meter N on device ... is unused, removing it" and deletes it, and
`Verify Meters in ONOS` fails with "Upstream meter is missing: 0 != 1".
For dt/tt/dt-fttb the file additionally supplies the ONOS app list, the
netcfg (sadis, kafka, dhcpl2relay, igmpproxy) and the OltFlowService
componentConfig, plus the servicesConfig that bbsim-sadis-server serves
to ONOS. Running those workflows without it loads att's service
definitions.
The values file is applied to voltha-infra only - both of its top-level
keys (onos-classic, servicesConfig) belong to that chart. It is appended
after the onos-classic --set flags; helm gives --set precedence over -f
regardless of order, so the NodePort overrides above still win.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XZ6zehezd23CktrW8jdcLN
Signed-off-by: serkantul <serkant@gmail.com>
serkantul
force-pushed
the
fix/voltctl-api-port-forward
branch
from
September 10, 2026 17:09
d86d105 to
f01384e
Compare
The previous commit sent examples/${WORKFLOW}-values.yaml to
voltha-infra only. That is where the onos-classic.* keys belong, and it
fixed att, but the file's other two top-level keys - servicesConfig and
bp_format - are consumed by the bbsim chart, not voltha-infra.
voltha-infra has no servicesConfig at all, so those keys were silently
dropped and BBSim kept serving att's service definitions to ONOS
through bbsim-sadis-server for every workflow.
That is why att passed while dt and tt failed:
dt Verify Subscriber Access Flows Added For ONU DT
No matching added upstream flow found for of:00000a0a0a0a0a0a in
TABLE 0 (in_port 256)
BBSim advertised hsia c_tag/s_tag 900 with eapol instead of dt's
c_tag 4096 / s_tag 900 (uni_tag_match 4096, bp_format ietf), so no
flow matched tests/data/bbsim-kind-dt.yaml.
tt Validate Subscriber DHCP Allocation
ONU port 256 not found in dhcpl2relay-allocations
tt needs four services - hsia, voip, vod and MC - and BBSim only
had att's one.
Verified on a kind cluster with an all-master VOLTHA 2.15 stack, BBSim
and one ONU. With the values file on both installs, sanity-kind-att,
sanity-kind-dt and sanity-kind-tt all pass.
Signed-off-by: serkantul <serkant@gmail.com>
Author
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.