Release Certification⚓︎
Release certification is the go or no-go signal for a platform release: for a given declarative core configuration, does the whole product loop work end to end? A harness applies the configuration to a real Kubernetes cluster, waits until the Kubernetes operator that manages the core reports it ready, verifies that the management agent is present and correctly configured, and then drives subscriber lifecycle scenarios through the 3GPP peer simulator. Each scenario produces a pass or fail; the harness aggregates them into one JUnit report per configuration.
What a certification run does⚓︎
| # | Phase | What is verified |
|---|---|---|
| 1 | Discover configurations | Every configuration directory holding a Site definition is certified in turn. |
| 2 | Apply overrides | Where the configuration ships an image catalog override, the images under test are substituted; where it ships session-management rules, they are installed as the rule set the agent mounts. |
| 3 | Apply the Site definition | The declarative description of the core is applied to the cluster. |
| 4 | Wait for readiness | The Site reports Ready and its observed generation is at least the applied generation, so a stale readiness from an earlier configuration cannot satisfy the wait. |
| 5 | Verify the agent | The management agent exists, is ready, and mounts the expected rule set; a core with no agent, or with a drifted component label, fails here even though the core itself is ready. |
| 6 | Wait for the simulator | The simulator reports ready on its own condition, kept separate from the core's readiness so that test scaffolding can never mask a core that is not ready. |
| 7 | Confirm images in use | When images were overridden, every pod in the namespace is polled until it runs the overridden references; the run certifies what it was asked to certify. |
| 8 | Optional readiness soak | Absorbs cold-start effects such as PFCP association and identifier-pool registration before traffic starts. |
| 9 | Run scenarios | Subscriber lifecycle scenarios are executed against the simulator's API; each scenario's assertions are evaluated against the core's own state endpoints. |
| 10 | Aggregate and tear down | Scenario results are collected into JUnit; the Site, rule set and image overrides are removed. A configuration that fails before scenarios run gets a synthetic failed test case carrying the full phase log, so the report covers the whole run. |
Certified configurations⚓︎
| Configuration | Shape | What its scenarios prove |
|---|---|---|
| Reference 5G core | One session-management function, one intermediate user-plane function and two user-plane functions, one per System, selected by session-management rules | Two subscribers attach repeatedly and land on different user planes; the assertion is on the UE address block each receives, so a subscriber placed on the wrong user plane fails. The active PFCP session count on that user plane is read from the network function's own statistics as ground truth. |
| Reference 5G core with a replicated database | The same shape with one change: the database runs as a three-node synchronous cluster | Any behavioural difference is attributable to the database change alone. Certifies schema migration and event persistence against the replicated database. Manual drills for database failover, the refusal to convert a running database between standalone and clustered mode, and rescaling are documented alongside it. |
Exit codes and reports⚓︎
The harness exits 0 when every configuration passes, 1 when configurations ran and at least one failed, and 2 when it could not proceed (cluster unreachable, configuration directory unreadable, required tools absent). The JUnit report has one test suite per configuration and one test case per scenario; a failure carries the phase log, including the last readiness status observed, so the cause is in the report rather than in a lost terminal.
When it runs⚓︎
Certification is run by Engineering against a managed test cluster before a release is published. It is not part of the per-change pipeline: it needs a real cluster with the network attachments the core requires, and it takes minutes per configuration. The configurations themselves are checked on every change: a unit test decodes every checked-in Site definition strictly, so a malformed configuration fails the ordinary pipeline even though the harness itself did not run.