...
ONAP applications can be divided into three main categories. Applications that are required at the design time, such as SDC, Policy creation, etc. Applications that support runtime time functions like A&AI, MSOsuch as AAI, SO, DCAE, SDN-CSDNC, APPC and AppVF-C. Finally, the applications that support administrative functions on the ONAP platform. As the number of applications grows, there is a need to have control over:
...
Any application based on the SDK will have implicit connectivity with a centralized ONAP Portal Core via a message-oriented middleware. It will be used for sending and receiving any data from the ECOMP ONAP Portal.
ONAP PORTAL CORE / RUNTIME
...
Any user seeking access to an ONAP application will first land on the ECOMP ONAP Portal Core where authentication will be performed. Based on the user’s access level, the ONAP Portal Core will let the user access different application widgets, and may also redirect them to their own run-time environments.
...
- Service Design and Creation (SDC): visual design tools for Services
- Policy creation (editing and conflict identification tools)
- Visual design tools for Analytic Applications (out-of-scope for first ONAP release)
Instantiating Services
The Portal offers a Virtual Instantiation Deployment (VID) GUI to trigger MSO SO instantiation of Services and components that have been certified and distributed for production. These services may include:
- Infrastructure Services (such as compute and storage resources)
- Network Services (Virtual Network Functions)
- Application Services (such as a load-balancing function)
VID reads the models created in SDC, and, in turn, forwards the appropriate information to MSO SO during the Service instantiation process.
Administration
From the ONAP Portal, administrators:
- access the same functionality accessible to users
- manage users and application admins
- onboard applications and widgets (developed using the Portal as a platform)
- edit the functional menu
...
Detailed Portal Architecture:
- How does this project fit into the rest of the ONAP Architecture?
- Please Include architecture diagram if possible - {+}https://wiki.onap.org/display/DW/Portal+
- What other ONAP projects does this project depend on? No dependecies. But will impact components - Policy, VID, SDC, DBC (DMaaP Bus Ctrl)
- How does this align with external standards/specifications?
- For security - O-Auth
- Are there dependencies with other open source projects?
- Application Authorization Framework (AAF)
...
- Primary Contact Person: Manoop Talasila
- Names, gerrit IDs, and company affiliations of the committers
- Manoop Talasila, talasila@research.att.com, AT&T
- Sunder Tattavarada, statta@research.att.com, AT&T
- Names and affiliations of any other contributors
- Sunder Tattavarada, st782s@att.com, AT&TAftab Syed Anwar, anwar@research.att.com
- Chris Lott, cl778h@att.com, AT&T
- Wei-Ting(Robert) Lo, wl849v@att.com, AT&T
- Anandarup Sarkar, as0481@att.com, AT&T
- Leimeng Shi, ls3297@att.com, AT&T
- Lorraine A Welch, lb2391@att.com, AT&T
- Abbas Fazal, af9900@att.com, AT&T
- Ikram Ikramullah, fi241c@att.com, AT&T
Farhan Mir, fm7890@att.com, AT&T
- Morales Victor, victor.morales@intel.com, Intel
- Gary Wu, gary.i.wu@huawei.com, Huawei
- Kwiecie? Krzysztof, Krzysztof.Kwiecien1@orange.com, Orange
- Kishore Koya, kk707x@att.com, AT&T (Primary Tester)
- Project Roles (include RACI chart, if applicable)
...
- JIRA project name: Portal
- JIRA project prefix: Portal-
| Wiki Markup |
|---|
*Repo name*: portal, ecompsdkos *Lifecycle State*: enhancement *Primary Contact*: Manoop Talasila *Project Lead*: Manoop Talasila *mailing list tag{*} \[Should match Jira Project Prefix\] *Committers*: talasila@research.att.com; statta@research.att.com *Link to TSC approval: *Link to approval of additional submitters:{*} |