R5 El Alto Release
EUAG decided that R5 El Alto will be a "maintenance/technical debt" release.
The El Alto release will be shortened and focus on internal (tech) debt and defect backlogs.
PTLs had taken short cuts to meet deadlines, working but want to make the platform more robust. PTL driven code fixes and code hardening.
S/W Enhancements (e.g. GUI enhancements) would be pushed to R6. Feature enhancements would be pushed to R6
R5 will be focused on Refactoring, JIRA backlog reduction, vulnerability issues, Test Coverage, Test Automation (CI/CD pipeline), Deployment procedure, Documentation.
R5 - Security Scans, scan code reports sent to PTL for major things to fix. Vulnerabilities have been built. Vulnerability management process. Security gates checklist.
No new functionality will be introduced in R5 for the General PNF Support Use Cases.
R6 GENERAL PNF USE CASES OVERVIEW:
|PNF PRE-ONBOARDING & ONBOARDING Use Case|
PNF Package delivery, Pre-onboarding and PNF Onboarding via SDC. In R5 El Alto focus will be on enhancements to the base functionality from R4 Dublin.
|PNF/VNF PREONBOARDING / ONBOARDING in R6 Frankfurt|
|CONFIGURATION WITH NETCONF||Enhancement to NETCONF support in ONAP supporting 5G and other use cases. Protocol is generic driven from RFC and the PNF does not assume any type of PNF. The main proposed addition is integration with AAF and external CA for NETCONF/TLS client certificate.|
|Configuration with NETCONF in Frankfurt/R6|
|PNF PLUG AND PLAY||PNF Plug and Play support for PNF discovery, Dublin Carry-over items, support by PRH (PNF Registration Handler)|
|PNF PLUG and PLAY in R6 Frankfurt|
|PNF S/W UPGRADE|
PNF Software Upgrade to update the software on a PNF, Dublin Carry-over items.
Goal 1: PNF S/W Upgrade Netconf support (PNF Generic)
Goal 2: 3GPP southbound based interfaces (controller to xNF or External Controller). An example API using 3GPP interfaces. (5G Specific)
|PNF SOFTWARE UPGRADE in R6 Frankfurt|
PNF USE CASE COMMITMENTS BY PROJECT:
The following table indicates commitment by project. The impacts have been accepted and are supported by the PTL of each ONAP Platform component and corresponding Jira Tickets are in place. There are three states:
N/A = A "N/A" means that there is no interaction, no dependency, and no work for that Use Case for that component.
? = A "?" means that there is not final commitment from the PTL for that project, and no Jira ticket exists yet.
YES = This means that (1) PTL INFORMED & COMMITTED - has agreed to support the changes needed for that Use Case, (2) DEVELOPMENT SUPPORT - there is development (company) support (3) JIRA TICKETS - and a Jira ticket exists. Please see the corresponding WIKI page for that Use Case to find out more details on impact, PTL support and Jira Ticket(s).
NOTE: The CTRLR column includes CC-SDK, CDS, SDN-C, APP-C. Including what used to be SDN-R has been under the SDN-C "umbrella".
|Use Case||SDC||VID||Portal||SO||AAI ESR|
|DCAE||OOF||Policy||CLAMP||DMaaP||AAF||VNF SDK||REQTS||Model S/C||OOM||VIM||Pomba||CIA||CLI||Consul||VF-C|
|S/W Upg ||YES||YES||N/A||YES||N/A||YES||N/A||N/A||N/A||N/A||N/A||N/A||YES||YES||N/A||N/A||N/A||N/A||N/A||N/A||N/A||N/A|
REQ = VNF Requirements Project. The VNF-RQTS project applies to both VNFs and PNFs. A "YES" here means that there are new requirements for the vendors.
Model S/C = Modelling Subcommittee. This U/C impacts the ONAP Platform Information and/or Data Model.
Ctrlr = This includes all of the controllers in ONAP including SDN-C, SDN-R, APP-C and VF-C
Stretch Goal (N/A) but if extra resources are available some changes may be made.
Note (1): x
Note (2): x