tests: add onboarding e2e suite#1178
Merged
Merged
Conversation
This was referenced May 15, 2026
eriknordmark
marked this pull request as ready for review
May 15, 2026 19:48
eriknordmark
requested review from
europaul,
giggsoff,
milan-zededa,
rene and
rouming
May 15, 2026 19:48
rene
reviewed
May 29, 2026
| eden eve onboard | ||
| stdout 'onboarded' | ||
|
|
||
| # Wait for the artefacts; zedclient writes them shortly after the |
Contributor
Author
There was a problem hiding this comment.
Apparently Anthropic has been inflitrated by some Brit (but I haven't seen other odd spelling) ;-)
rene
approved these changes
May 29, 2026
rene
left a comment
rene
left a comment
Contributor
There was a problem hiding this comment.
LGTM other than the typo to be fixed
Adds a new test directory that exercises EVE's onboarding flow against a live device booted by the standard eden setup. The initial test verifies the on-device artefacts produced by the onboarding loop — the kernel hostname matches the controller-issued UUID, the UUID file under /persist/status is parseable, and a hardwaremodel string was written. Together they cover the post-onboard publishing path and the full event loop that Go unit tests in the eve repo cannot reach. Signed-off-by: eriknordmark <erik@zededa.com> Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Adds two more scenarios to the onboarding e2e suite that target the dark code paths in pkg/pillar/cmd/client that the initial happy-path test cannot reach. `server_changes_at_runtime` writes a deliberately-wrong controller URL into the CONFIG partition via `eve config mount`, reboots, and verifies the boot brings up cmd/client against the bad URL (exercising the LedBlinkInvalidControllerCert escalation in tryRegister), then restores the original URL via an in-VM reboot — controller-side reboots cannot recover the device once it is pointing at an unreachable controller. `pre_provisioned_uuid` reuses the same wrong-server lever to keep nim's DPC state at FailWithIPAndDNS while cmd/client's 5-second t1 timer fires, so the "already have UUID + checkpoint; declare success" shortcut branch in Run() is exercised. The witness is the unique log line at client.go:433, searched in /persist/newlog (active + gzipped archives). Both tests use a small retry_ssh helper to ride out the ~minute of ssh banner-exchange flakiness that follows a reboot, and rely on `eden controller edge-node reboot` for the first reboot (EVE still reaches adam at that point) and an in-VM `reboot` for the recovery. Signed-off-by: eriknordmark <erik@zededa.com> Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Covers the dark `case http.StatusForbidden` branch in selfRegister (pkg/pillar/cmd/client/client.go:671-672) that raises LedBlinkOnboardingFailureNotFound when the controller rejects an onboarding cert that the device cryptographically possesses but that is not present in the controller's pre-registration set. The branch was effectively unreachable until lf-edge/adam#155 brought adam in line with the eve-api spec (APIv2.md §/register: "Valid credentials without authorization: 403"). The scenario captures every onboard-cert + device record that matches this device's serial, DELETEs them via adam's /admin/onboard and /admin/device admin endpoints, wipes /persist/status/uuid and /persist/checkpoint/controllercerts on EVE, in-VM reboots, asserts LedBlinkCounter=18 (OnboardingFailureNotFound), POSTs the saved onboard cert back, reboots again, and verifies the device reaches LedBlinkCounter=4 (Onboarded) with a fresh UUID on disk. A short retry_ssh wrapper rides out the ~minute of ssh banner-exchange flakiness right after each reboot, mirroring the pattern in the existing server_changes_at_runtime and pre_provisioned_uuid scenarios. The admin curl uses 127.0.0.1:adam.port (host-side docker port mapping) because adam.ip in the eden config is the EVE-side IP, not the host side. Signed-off-by: eriknordmark <erik@zededa.com> Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
eriknordmark
force-pushed
the
client-onboarding-e2e
branch
from
May 29, 2026 20:24
91871a1 to
9a932cc
Compare
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
2 participants
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.
Summary
Adds an onboarding e2e suite under
tests/onboarding/that exercisesthe cmd/client agent in EVE against a live device booted by the
standard eden setup. Four scenarios:
onboarding_status— happy path. Aftereden eve onboard, asserts/persist/status/uuidparses, the kernel hostname matches that UUID,and
/persist/status/hardwaremodelis non-empty.server_changes_at_runtime— writes a deliberately-wrong controllerURL into the CONFIG partition via
eve config mount, reboots, andverifies the boot exercises cmd/client's wrong-cert-fetch path
(
LedBlinkInvalidControllerCertescalation). Recovers via an in-VMreboot since EVE cannot reach adam to receive a controller-side
reboot directive once the bad URL is active.
pre_provisioned_uuid— uses the same wrong-server lever to keepnim's DPC state at FailWithIPAndDNS while cmd/client's 5-second t1
timer fires, exercising the "already have UUID + checkpoint; declare
success" shortcut branch in
Run().server_returns_403— drives the un-onboard flow: removes thedevice's adam-side onboard cert + device record via the admin
endpoints, wipes
/persist/status/uuid+/persist/checkpoint/controllercertson EVE, reboots, asserts
LedBlinkOnboardingFailureNotFound(=18),POSTs the onboard cert back, reboots again, asserts re-onboarding
succeeds. Requires lf-edge/adam ≥ 0.0.79 (the first release that
includes server: return 403 on unregistered onboarding cert/serial adam#155, which brings
/registerin line withthe eve-api spec: 403 for cert/serial that isn't pre-registered).
Paired with defaults: bump DefaultAdamTag from 0.0.75 to 0.0.79 #1180 which bumps
DefaultAdamTagso thedefault eden setup pulls the right adam.
Complements the cmd/client Go unit tests in lf-edge/eve#5957 and
lf-edge/eve#5958. Combined with the unit tests this suite raised
pkg/pillar/cmd/clientblock coverage from 0 % to 87.36 %(eden e2e alone gets 71.18 %; unit-only is 53.66 %).
Two further scenarios from the original plan were left out of this
PR; both need an un-onboarding harness that's now built into
server_returns_403, so they become follow-ups:wrong_server_url(un-onboarded variant) — overlaps withserver_changes_at_runtimeso the marginal coverage is small.register_then_getuuid_interleave— needs adam to know the deviceUUID but reject the onboard cert (a contrived state).
The original
cert_miss_refetchscenario was found unreachable frome2e during analysis: cmd/client's
fetchCertChainrefreshes thein-memory cert hash before
doGetUUIDever runs, soSenderStatusCertMisscannot fire in the same
Run(); the branch is already covered by theunit test
TestDoGetUUID_CertMissSchedulesTimer.Test plan
eden setup && eden start && eden test ./tests/onboarding/ -vfrom a clean eden workspace passes all four scenarios.
eden eve collect-coverageafter the run shows the cmd/client coverage numbers above
(verified locally against an EVE built with
make COVER=y).