...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
| Info |
|---|
Approved by the TSC on TSC 2022-12-08 |
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.
...
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.
...
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:
| Info | ||
|---|---|---|
| ||
All project proposals require an review by the Architecture subcommittee BEFORE being submitted to the TSC. The questions in this section need to be filled in by the time you meet with the Arch subcommittee. |
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.
...
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 17 and spring boot
- using web services for it's components
...
- 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.
- Upstream open source projects:
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
- Code is ready to be uploaded
- 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:
Facts | Info |
|---|---|
| Jira Project Name | Portal NG |
| Jira Key | PORTALNG |
| Project ID | |
| Link to Wiki Space (if |
Release Components: (add/delete rows as necessary)
Component Name | Repository name | Component Description | |
|---|---|---|---|
| ui | portal-ng/ui | The Portal user interface is an Angular web application | |
| bff | portal-ng/bff | The Portal Backend for Frontend (BFF) bundles all API access for the portal-ui and reduces the complexity of API calls for the UI. It is a proxy application that in some cases aggregates multiple calls to southbound systems (the ONAP systems) and also potentially passes less complex objects to the UI. | |
| preferences | The portal-service is a spring boot backend application that serves so called Tiles for the dashboard page of the portal-ui and encrypted Keys for the cookie authentication of some ONAP web UIs like the SDC. | portal-prefsportal-ng/preferences | The portal-prefs is a spring boot backend application that serves user preferences, like column order of data tables in the portal-ui or which dashboard component is viewed on which place in the portal-ui. The data are stored in the portal-prefs-db. |
| history | portal-ng/history | The portal-history is a spring boot backend application that server user history, such as info about user searches, instantiations, deletions. This data is stored for predefined amount of time (for example 72 hours) then they are automatically deleted. | |
| portal-bff-cache | FUTURE ROADMAP The "portal-bff cache" caches certain responses received from systems such as: A&AI, SDC, CDS. The cached "REST requests" contain the data for required by the portal-ui for:
The request from the portal-ui will get the response from the cache if available. The cache will be refreshed after each request too. |
Resources committed to the project: (add/delete rows as necessary)
Role | Name (use @ macro) | Linux Foundation ID | Email Address | Location |
|---|---|---|---|---|
| PTL | fiete.ostkamp@telekom.de | |||
| Committers | Münster/Germany | |||
| Stefan Rothmajer | Kosice/Slovakia | |||
| Stefan Dierichs | s.dierichs@telekom.de | Münster/Germany | ||
| Marian Vaclavik | marian.vaclavik@telekom.com | Kosice/Slovakia | ||
| Köln/Germany | ||||
| georg.schweflinghaus@telekom.de | Bonn/Germany | |||
| Other Contributors | ||||