Repository navigation
Proposal: a nightly CNTi cert check for the Open5GS chart, and the badge once it passes #245
Description
Summary
We'd like to propose a nightly GitHub Actions job for the open5gs chart that installs the 5G core on a kind cluster, runs the CNTi Test Suite's cert tests against it, and shows the result as a badge in the README once the chart passes.
It doesn't pass today. On the chart's defaults the result is 13 of 19 essential tests, two short of the threshold of 15, and a badge would show that. We don't propose to publish a failing badge. We propose the check now, because the one step that takes the chart over the threshold is already in review: the image change in Gradiant/5g-images#490. With it the expected result is 16 of 19, with no change to the charts.
CNTi and the test suite
The Cloud Native Telecom Initiative (CNTi) is an LF Networking project that works on cloud native practices for network functions on Kubernetes; its reference workloads are a 5G core (free5GC) and a 5G RAN. Its test suite installs a workload on a cluster and checks it while it runs: probes, SIGTERM handling, rolling updates and rollbacks, scaling, draining a node, and the security posture of the pods. The cert run is its essential subset, 19 tests with a pass mark of 15. testsuite-action runs it in a repository's own CI and publishes the result as a badge.
Examples of charts that show the badge today: Aether SD-Core, a 5G core control plane (omec-project/sdcore-helm-charts, 16 of 19), or Jitsi Meet (jitsi-contrib/jitsi-helm, 18 of 19). Open5GS would be an additional 5G core with one.
Why it fits the Open5GS chart
- It's the check this chart has been getting fixes for. The HPA gate (open5gs: create the HorizontalPodAutoscaler only when autoscaling is enabled #233), the SEPP's user and group (open5gs: run the SEPP as the image's user and declare the group in every chart #241), the default requests (Set default resource requests for Open5GS workloads #243) and the UPF probes (open5gs-upf: liveness and readiness probes by default #242) all came out of running this suite against the chart. A nightly run keeps that going without anyone running it by hand, and catches a regression within a day: a new image, a dependency bump, a values change.
- It adds what
ct installdoesn't check. Your CI installs the charts on kind. The cert tests also check how the functions behave once they run: that they survive a node drain, scale up and back, roll an image forward and back, stop on SIGTERM, and keep the security posture the defaults promise. - It runs on what you already have. A GitHub-hosted runner, the same
helm/kind-actionyour CI uses, about 30 minutes, no secrets. - The badge is a statement operators look for. A CNTi cert badge on the README says, with a nightly run behind it, that the chart follows the cloud native telecom practices an LF Networking suite checks, vendor-neutral and verifiable by anyone who opens the run. For a 5G core that people evaluate for labs and deployments, that's a reason to be chosen.
Where the chart stands
Measured on a fork, chart defaults, suite v2.2.0, with only these settings: the 5G core without the EPC parts, WebUI and subscriber population; MongoDB pinned to an image that still exists, without persistence; the SMF not looking for a PCRF that isn't deployed. None of them changes a practice the tests judge.
| Chart | Result | Run |
|---|---|---|
main today |
13 of 19 | 37660095445 |
main with the image from Gradiant/5g-images#490 |
16 of 19, expected |
The six tests that fail today, and why:
| Test | Cause | What would change it |
|---|---|---|
sig_term_handled |
entrypoint.sh runs the daemon as a child of the shell, so SIGTERM never reaches it |
exec in the entrypoint: Gradiant/5g-images#490 |
specialized_init_system, zombie_handled |
The image has no init process to forward signals and reap orphans | tini as the entrypoint: Gradiant/5g-images#490 |
memory_limits, cpu_limits |
No default limits | Your decision; #240 is open for the memory limit, and we don't ask for a CPU limit |
privileged_containers |
The UPF's main and tun-create containers are privileged for the TUN device |
A design change; not proposed |
The step to the threshold
Gradiant/5g-images#490 adds tini and exec to the open5gs image. The three tests it addresses check exactly what those two provide: a PID 1 that forwards signals and reaps orphans, and a daemon that receives SIGTERM. 5g-images rebuilds and pushes the image under the same tag on merge, so the charts need no change: the next run picks it up, and the expected result is 16 of 19, one above the threshold. The remaining three failures are the limits and the UPF's design, and the badge would show 16 of 19 honestly.
Proposal
- Now: a workflow
.github/workflows/cnti.yml, nightly and by hand, read-only, with the suite's configuration in.github/cnti/. Until the chart passes, it reports the result in the job summary and the results artifact without failing the job, so a red nightly doesn't become noise. The PR follows this issue. - When the result passes: the CNTi badge with the score, published by the action to an orphan branch
badges. Only runs onmainget a write token for it; pull request runs use the same steps read-only. It's the badge SD-Core shows; Jitsi chose GitHub's workflow badge instead, which is also possible. - Version pin: a released suite version, bumped on purpose after reading the release notes, never
latest. - Scope: the 5G core on chart defaults, as measured above; the EPC charts are not tested.
Questions
- Would you like the nightly cert check in this repository, and the badge once it passes?
- Could someone look at open5gs: start through tini and exec the daemon 5g-images#490? It's the one change between the chart and a passing badge, and it's a one-line entrypoint fix plus
tini. - Anything you'd like done differently in the job?
Activity