Project Common Name: portalng

Project Overview:

Project description:

Background

ONAP had a portal project but this project was terminated and archived. PortalNG is supposed to be a new start and fill the gap.

Deutsch Telekom AG (DTAG) is developing a portal for their own use cases to accomodate their particular needs of a single point to start interaction with network automation.
Goal is to solve specific network requirements for ORAN while staying generic enough to cater for future use cases in other network areas.

Consequently the generic parts of the DTAG porta could be reused by the ONAP community as the inital core of a successor of the portal with the project name "cockpit".

The state of the DT portal was presented in an LFN session and video and slides can be found here.

Project goal and vision

Provide a state of the art web based GUI that serves as the first discovery point for the ONAP framework, it's existing web applications and functions.

Onboard users with an adaptive GUI following a "grow as you go" approach covering "playful discovery" up to expert mode.

Wherever possible hide complexity of network automisation by guiding the user. 

Provide a framework for user administration and user authorization.

Scope and benefits for ONAP

Available starting point for current ONAP

• Build on top of an existing and tested base implementation that was developed during the last 18 month by a scrum team at DTAG
• As a web based GUI it will serve as a discovery point for the existing ONAP system web GUIs 
• Support for internationalization
• Support for theme implementation

Scope:

In Scope: Please provide an overview of the intended scope of the project over several years, not just what you hope to accomplish for the project's first release.

• Starting point for user management and authorization
• App starter for discovery and access of ONAP applications
• Dashboard for status of ONAP services in cloud
• History of portal actions
• Model discovery
• Model instantiation
• Instance managment
• Topology view
• Develop into a framework to provide generic network automation while enabling specific domain functions

Out of Scope: 

Features / functionality being developed: 

• • 1st release content: Initial PoC
  • 2nd release content: Full project. First existing ONAP applications enabled to build on authorization
  • 3rd release content: 

New interface/API specifications proposed: 

None

Architecture Alignment:

Architectural Fit

• • How does this project fit into the rest of the ONAP Architecture?
  • Architecture diagram of your project: 
  • What upstream ONAP projects does this project depend on? 
  • What downstream ONAP projects are expected to leverage this project?
  • Project & Component Overlay:  

PortalNG will provide the portal component that is already forseen in the ONAP architecture blueprint.

PortalNG internal architecture

The PortalNG architecture is centered around microservices that will be invoked by a single page application running in the users browser.

Currently each of them is an a separate repository.

The two main parts are the Portal Frontend an Angular application and the "Backend For Frontend" BFF micros service.

The Portal Backend wraps up the "business logic" to provide simplified REST endpoints for the frontend. To provide the logic the Portal Backend will connect to various ONAP services.

NOTE: The architecture provided below shows 

Tech stack

The PortalNG is developed:

• as a Single Page web application using the Angular framework for it's frontend services
• with a backend service based on Java 11 and spring boot
• using web services for it's components

It uses plain vanilla

• KeyCloak server for Identity and Access Managmenet
• NGINX as a reverse proxy e.g. for deliveing the single page application
• MongoDB to store preferences and history entries

• Interoperability  

  • SDO (Standards Developing Organization) specifications supported: 
  • APIs/Interfaces:
    • http/https northbound towards web browser
    • southbound ONAP APIs used as they are
  • Information/data models:
    • Relies on customer data from keycloak
    • Current approach is to work dataless except for caching southbound requests
  • If there is an existing ONAP project that does something similar to this project explain why this being a new stand-alone project?
    • ONAP project is unmaintained. Telekom has a portal it uses internally and would like to donate parts of it's code

• Other Dependencies

  • Upstream open source projects:
    • Keycloak 
    • NGINX
    • MongoDB
  • Non ONAP APIs/Interfaces:
    • KeyCloak
  • Specific IDE integration requirements:
    • None
  • Integration Testing: 
    • TBD and aligned with existing ONAP processes. Extensive E2E tests for DT use cases existing but not yet stripped down for smaller feature set
  • etc.

Community Alignment:

• Vendor Neutrality:
  • The PortalNG does not include any vendor specific code nor require any vendor specific integrations (e.g. Element Manager)
• Seed code Location (if any):
  • In-House
• If "In-House" please answer the the following questions:
  • Code is ready to be uploaded
    • Theoretically yes
  • Approved by project leadership team
    • approval from DT open source responsible available, approval from DT project lead available
  • All proprietary trademarks, logos, product names and internal company secrets were removed
    • yes
• No waivers to ONAP policies (including IPR) are required by this project.
  
  TODO
  

• Plan for providing education to onboard the ONAP developer community : Currently no plan available for this.
  
  TODO
  

Jira Information:

Release Components: (add/delete rows as necessary)

Resources committed to the project: (add/delete rows as necessary)