Release 2.0.0¶
Release 2.0.0 (2026-10-23) rebuilds the core of OpenOP. The Open Exposure Gateway (OEG), Service Resource Manager (SRM) and Federation Manager (FM) are rewritten on FastAPI, each with its own PostgreSQL database, and exchange commands and events over a NATS DataBus. Keycloak secures every API. The Portal gains a backend, the Transformation Function SDK becomes openop-tfsdk with one adapter contract, and the Data Lab catalogue ships for the first time.
Components¶
| Component | Version | Tag | Artefacts |
|---|---|---|---|
| Open Exposure Gateway | 2.0.0 |
v2.0.0-release |
labs.etsi.org:5050/oop/code/open-exposure-gateway:2.0.0 |
| Service Resource Manager | 2.0.0 |
v2.0.0-release |
labs.etsi.org:5050/oop/code/service-resource-manager:2.0.0 |
| Federation Manager | 2.0.0 |
v2.0.0-release |
labs.etsi.org:5050/oop/code/federation-manager:2.0.0 |
| Transformation Function SDK | 2.0.0 |
v2.0.0 |
Python package openop-tfsdk==2.0.0 (ETSI GitLab package registry) |
| Portal | 2.0.0 |
v2.0.0-release |
labs.etsi.org:5050/oop/code/portal:2.0.0 |
| AI² | 2.0.0 |
v2.0.0-release |
labs.etsi.org:5050/oop/code/ai2/mcp_module:2.0.0, labs.etsi.org:5050/oop/code/ai2/ai_agent:2.0.0 |
| Helm chart | 2.0.0 |
v2.0.0-release |
Chart oop-platform in oop-platform-chart/ |
| Ansible automation | 2.0.0 |
v2.0.0-release |
Playbooks for k3s and existing clusters, and the end-to-end lab |
| Data Lab | 0.1.0 |
v0.1.0-release (code); Helm subchart datalab 0.1.0 in v2.0.0-release |
labs.etsi.org:5050/oop/code/data-lab/data-lab-api:0.1.0, labs.etsi.org:5050/oop/code/data-lab/data-lab-admin-ui:0.1.0 |
| Architecture and specifications | Spec version 2.0 | v2.0.0-release |
Spec bundle |
The Data Lab has its own version, 0.1.0, and is released separately from the Release 2. It is new in this release and is off by default, so existing installations are unaffected until it is enabled.
Highlights¶
- CAMARA APIs at pinned versions, each checked by a conformance suite against the vendored spec: Edge Application Management 0.1.0-alpha.1, Quality on Demand 1.1.0, Traffic Influence 0.10.0 and Location Retrieval 0.5.0.
- Keycloak across the platform. OEG checks every token and the role and scope of each operation. The Portal signs users in with OIDC (Authorization Code with PKCE), and developers create their own API clients. Partner operators authenticate to FM with OAuth2 client credentials.
- Asynchronous core. OEG sends long-running work to SRM as DataBus commands; results come back as events and CAMARA CloudEvent callbacks.
- Federation alignment with GSMA OPG.04 v6.0 (EWBI API 1.4.0). Support for partner registration, agreements, zone exchange, federated deploy and terminate, and inbound QoD and location. Operators manage it from the Portal's Federation page.
- Multi-zone deployments, Traffic Influence and device location through SRM and TF-SDK.
- TF-SDK 2.0 with one adapter contract and a separate topology discovery interface. Control paths are declared in one bootstrap file.
- AI² manages edge applications, QoD, Traffic Influence and location, calling OEG with the user's own token.
- Data Lab 0.1.0, a DCAT-AP 3.0 metadata catalogue on piveau for the 6G-DALI Metadata Application Profile.
Compatibility¶
The 2.0 components are released and tested together. Mixing 1.x and 2.x components is not supported.
| Dependency | Version in the reference deployment |
|---|---|
| Keycloak | 26.7.3 (realms oop and federation, imported by the Helm chart) |
| PostgreSQL | 18.6, one instance with a database and role per component |
| NATS | 2.10.29 (Helm chart 1.2.10), JetStream on |
| Python | 3.12 for OEG, SRM, FM and the Portal; 3.10 to 3.13 for TF-SDK |
| Kubernetes reference environment | kind 0.20 or newer, kubectl 1.25 or newer, Helm v3 |
Upgrading from 1.0.0¶
There is no upgrade path from 1.0.0: remove the 1.0.0 installation and deploy Release 2.0.0 from scratch, as in Deploy with Helm. Nothing from 1.0.0 is carried over. Each component's notes list its breaking changes.
Known limitations¶
Each component page lists its own. These affect the platform as a whole:
- Not for production. The reference Helm deployment targets kind, for development, integration testing and demos. There is no ingress, and clients call OEG directly.
- DataBus delivery between OEG and SRM is not durable. A lost command is not resent, and CAMARA callbacks are sent once.
- Reads and deletes are scoped to the App Provider, not to their organization.
- Quotas, rate limits, usage records and charging are not enforced.
- No metrics. Logs are the only observability signal.