CAN bench runs on the latest Zelos release, without its workarounds

[michael-zelos]

Summary

The CAN bench now runs on the current Zelos release: agent 26.0.9, CLI 0.1.10 and SDK 0.0.12. Everything it carried to work around older releases is gone. The two can-bench blog posts link to this code.

Rendered notebook pages came out unreadable, so the bench chmod-ed them as root. The same went for recorded traces, and the entrypoint set umask 022 in the belief that it was the cause.

Cause. CLI 0.1.9 wrote its outputs mode 0600, owned by the container's root (zeloscloud/src#1505). The umask was never the cause.

Fix. CLI 0.1.10 writes them 0666 & umask. The chmod a+r step in just test and the entrypoint's umask go. CI's artifact upload reads the pages as the runner user, so it proves the fix.

The extension install needed its version spelled with a leading v.

Cause. CLI 0.1.9 matched the marketplace tag literally (zeloscloud/src#1491).

Fix. CLI 0.1.10 takes either spelling. The comment that warned about it goes.

Bumping the agent with --listen-address '[::]:2300' would bind IPv4 only, with a warning.

Cause. Agent 26.0.9 no longer binds [::]. It falls back to 0.0.0.0 and warns.

Fix. The flag goes. The default, 0.0.0.0:2300, is what the bench wants.

just record, the traces/ mount and traces/dcdc-defect.trz were dead. They fed the first notebook suite, which checked a committed recording. Since 96b2fdf the two notebooks read the live bench, and nothing reads the recording.

The apt source was [trusted=yes]. The repository is signed now. The image uses the keyring and Signed-By, as the install docs do.

The README described an older app and extension.

• It now names the Data view, which holds the Data Sources section where New agent sits.
• It named signals vcan0/... and a vcan0_raw source. Since extension v0.1.15 they publish under CAN/vcan0/..., with raw frames at CAN/vcan0/Frame.
• Its versions table now lists the agent, CLI and SDK this PR pins.

Versions

	Before	After
Zelos agent	26.0.8	26.0.9
Zelos CLI	0.1.9	0.1.10
zelos-sdk[notebook] in both notebooks	>=0.0.12a2	==0.0.12
CAN extension	v0.1.17	v0.1.17 (still the latest)

Size

One commit. +22 / −46 lines across 7 files, plus the deleted 124 KB dcdc-defect.trz. No tests change; the bench's tests are its two notebooks.

Behavior changes for review

• just record is gone, with the traces/ mount and the committed recording.
• The agent listens on 0.0.0.0:2300, its default. It no longer asks for [::].
• The notebooks pin zelos-sdk[notebook]==0.0.12 exactly, so a tagged checkout resolves the same SDK.
• tzdata stays in both notebooks. Removing it broke both in CI, with ArrowInvalid: The zoneinfo module or pytz package must be installed. The SDK returns time-zone-aware timestamps, and neither it nor the agent image supplies the zone data.

Rollout

The two can-bench blog posts (zeloscloud/src#1530) clone and link the can-bench-v1 tag. After this merges, can-bench-v1 moves to the merge commit. The posts are not published yet, so nobody has cloned the old tag from them.

Testing

• can-bench CI on e2364fe: run 37214292717, green in 5m41s.
  • The image installs agent 26.0.9 from the signed source, CLI 0.1.10, and CAN extension 0.1.17.
  • bench-health passes 8 of 8 checks, and dcdc-respects-allowance passes 1 of 1, on the good build.
  • The test-results artifact uploads both rendered pages, with no chmod.
• can-full CI on e2364fe: run 37214292734, green.
• The first push, without tzdata, failed both notebooks on missing zone data (run 37213553619). That run had already built the images, installed the extension and brought the bench up.
• Not tested: connecting the app to the bench over the published port, and just flash defect. CI reaches the agent from inside its container and runs only the good build.