ONAP Frankfurt Release Architecture Requirements
- Stephen terrill
- Chaker Al-Hakim
- Fernando Oliveira
The Architecture Requirements are Summarized here: The full release requirements (including Architecture requirements) are captured here: Frankfurt Release Requirements;
Label with stories with the projects that are impacted and include a description of that impact
These are listed with EPIC, then the following stories. The Epics are added manually, hence a complete list of Epics are included below.
To appear here, the JIRAs need the label ARC-REQ-FRANKFURT. Mark the release as Frankfurt
EPIQs and stories here should be approved by ArchCom
The ones that are "agreed" in the architecture sub-committee are marked as: This is still to be decided.
Summary / Status
Requirement/UseCase/... | Status |
|---|---|
Orchestration Scenarios | ArchCom approved ONAPARC-320: Orchestration scenarios ArchitectureIn Progress |
LCM API Evolution | ArchCom approved |
Edge Automation | Distributed Management Task Force - not ArchCom approved
Questions: still to be answered: |
3rd Party Operational Domain Controller | ArchCom approved for current direction. Note: Not full functionality in Frankfurt. One open issue to resolve as to whether the external service needs to be wrapped in an ONAP service to have consistent orchestation approach (or not). |
Service Resolver | Not Yet Archcom approved |
Model Driven ONAP << req >> | Not Yet Archcom approved |
Orchestration of Contain Based VNFs <<>> | Frankfurt Release ?? |
Applications on ONAP <<?? >> | Not Yet Archcom approved |
API-GW <<>> | There will not be a proposal for Frankfurt. |
Runtime DB << >> | Status: need and concept OK by Archcom:ONAPARC-514: Run-time DB (was RT DB)In Progress |
5G / ORAN & 3GPP Standards Harmonization | Status: Archcom approved |
ONAP CLI for VNF <<??>> |
Status: Note yet Archcom approved |
Slicing Evolution https://lf-onap.atlassian.net/browse/REQ-60 https://lf-onap.atlassian.net/browse/REQ-158 | Not Archcom Approved |
Multidomain optical service | Archcom Approved https://lf-onap.atlassian.net/browse/ONAPARC-519 |
Integrate Acumos with DCAE https://lf-onap.atlassian.net/browse/REQ-166 Self Service Control Loop | Archcom approved |
xNF licencing with ONAP | Archcom approved (principles) (licening server outside ONAP) https://lf-onap.atlassian.net/browse/ONAPARC-520 |
ETSI catalogue as a common service | Archom approved. Part of ETSI-ONAP alignment requirements |
CDS support of K8S | Archcom approved https://lf-onap.atlassian.net/browse/ONAPARC-522 |
Analytics (or VNF) at the edge using Akrono antaticis orchestrated by ONAP | Not Archcom approved https://lf-onap.atlassian.net/browse/ONAPARC-519 |
Orchestration Scenarios: ONAPARC-403
REQ-101: ETSI Alignment SupportDone
Status: Archcom approved: ONAPARC-320: Orchestration scenarios ArchitectureIn Progress
Controller Evolution:
Controller Evolution towards combined GNFC: https://wiki.onap.org/download/attachments/53248195/Controller%20EvolutionElAlto04012019.pptx?version=2&modificationDate=1554220494764&api=v2
STATUS: The approach has been approved by ArchCom ONAPARC-234: Controller EvolutionOpen
https://lf-onap.atlassian.net/browse/INT-1131
https://lf-onap.atlassian.net/browse/SO-2070
Edge Automation, (Ramki to inform)
ONAP 3rd Party Operational Domain Manager
Status: Architectureal Direction approved for current direction. Note: Not full functionality in Frankfurt. One open issue to resolve as to whether the external service needs to be wrapped in an ONAP service to have consistent orchestation approach (or not). https://lf-onap.atlassian.net/browse/ONAPARC-509
REQ-17: Third Party Operational Domain ManagerDone
Service Resolver:
Status: Not Archcom Approved (https://lf-onap.atlassian.net/browse/ONAPARC-507)
https://lf-onap.atlassian.net/browse/REQ-13
Model Driven ONAP
Status: Not yet ArchCom approved (https://lf-onap.atlassian.net/browse/ONAPARC-436)
Orchestration of Container Based VNFs (Srini)
???
Applications on ONAP
Status: Not yet ArchCom approved (https://lf-onap.atlassian.net/browse/ONAPARC-500)
API-GW
Status: Closed - there will not be a proposal for frankfurt timeframe
ONAPARC-494: API Management / API GW proposalClosed
RunTime DB
Status: direction approved, some more work to be done on project aspects (not an archcom issues) and flows:ONAPARC-514: Run-time DB (was RT DB)In Progress
CONFIGURATION PERSISTENCE SERVICE R6
5G / ORAN & 3GPP Standards Harmonization
Status:ArchCom ApprovedONAPARC-516: 5G / ORAN & 3GPP Standards HarmonizationClosed
REQ-38: 5G / ORAN & 3GPP Standards HarmonizationDone
ONAP CLI for VNF
Status: Note yet Archcom approved
ONAPARC-478: ONAP CLI and ArchitectureOpen
Slicing Evolution
https://lf-onap.atlassian.net/browse/REQ-60https://lf-onap.atlassian.net/browse/REQ-158https://lf-onap.atlassian.net/browse/REQ-159
Multidomain Optical Service
Status: Archcom approved https://lf-onap.atlassian.net/browse/ONAPARC-519
https://lf-onap.atlassian.net/browse/REQ-37
Integrate Acumos with DCAE
Status: not ArchCom approved
https://lf-onap.atlassian.net/browse/REQ-166
Self Service Control Loop
https://lf-onap.atlassian.net/browse/REQ-9
xNF licencing.
Status: principles archcom approved. https://lf-onap.atlassian.net/browse/ONAPARC-520
Misc:
Orchestration of container based VNFs (Srini)?
Service mesh (srini/mike)??
ONAP CLI For VNF (NB) and architecture (also make sure Dan Timony joins)
Service Resolver (Rene/Seshu)
DBaaS (what has been done, what we should do next) - (Yuri, Mike, Joanne)?? (session at subcommittee mtg).
Centalized DB technologies for the ONAP platform applications to use. DB is responsible for their own schema.
Notes: to be removed at the end.
Assume that slicing is driven by the use case work as per in previous releases, and this will implicitly cover the needs for the alloted resource and hierarchal orchestration.
The full list of the Epics are included here. This is to identify if there is a missing Epic above.
Stories All stories and sub-tasks.