Project Name:

  • Proposed name for the project: External System Register
  • Proposed name for the repository: esr

Project description:

  • ONAP components need to talk with external systems such as VIM/VNFM/vendor SDNC/EMS to orchestrate a network service, for example, VF-C need to talk with VNFM to deploy a VNF. So they should get the information of available external systems from a registry before call the Interfaces of these external systems.  ESR provides a service to centralized management of the information (name, vendor, version, acess end point, etc.) of external systems. So the ONAP components can get the system information with unified API from a logical single point. 

    Note: This project is proposed to be a sub-project of A&AI.

Scope:

  • This project provides a service to centralized management of external systems. 
    • Register/query/update/delete function of external system, such as VIM/VNFM/EMS/vendor SDN Controller. Users can register/update/delete external systems to ESR with API. And Multi-Vim/VF-C, for example, can query and talk to external systems with the query API. 
    • Provide a portal to manage the external systems.
  • This project will also check whether the external systems are reachable, and store the health status. So that other components can determine whether the systems are available based on the status.

    Merge with A&AI

    Original ESR Scope (proposed at 5/14/17)Merge Plan with A&AI (decided at 7/10/2017)
    Provide the API to register/query/update/delete external system, A&AI is the data storage back-endcontribute these function to A&AI
    Provide the Portal for user to register/query/update/delete external systema function of ESR which would be a sub-project of A&AI
    check whether the external systems are reachable, and store the health status to A&AIa function of ESR which would be a sub-project of A&AI

Architecture Alignment:

  • How does this project fit into the rest of the ONAP Architecture?
  • What other ONAP projects does this project depend on?
    • A&AI (store the external system data and status to A&AI)
    • MSB
  • What other ONAP projects will call the API from ESR?
    • Multi-Vim
    • VF-C  
    • ONAP SDN-C ?
  • Are there dependencies with other open source projects?

Resources:

Other Information:

Use the above information to create a key project facts section on your project page

Key Project Facts

Project Name:

  • JIRA project name: esr
  • JIRA project prefix: esr

Repo name:
Lifecycle State:
Primary Contact: li.zi30@zte.com.cn
Project Lead:
mailing list tag [Should match Jira Project Prefix] 
Committers:

Zi Li li.zi30@zte.com.cn 
Qi Sun sun.qi310@zte.com.cn

*Link to TSC approval: 
Link to approval of additional submitters: 


  • No labels

4 Comments

  1. Good morning Li.

    I believe that this proposal should be combined with the Active and Available Inventory project.

    We could re-use and enhance (if necessary) the existing AAI source code to perform similar interactions with external systems.

    Have you taken a look at the AAI Architecture (Active and Available Inventory (AAI)

    and source code https://gerrit.onap.org/r/#/admin/projects/aai/ ?

    Feel free to contact Manisha Aggarwal and Colin Burns if you need any additional information about the AAI project proposal.


    1. Actually, ESR is realized based on A&AI, ESR will store information data to A&AI. Beyond store information data, ESR has some business logic to deal with, such as information verification, which is out the scope of A&AI.

      Let's take VIM register as an example,  multi-vim sent the authentic url, tenant, username and password of VIM to ESR. ESR try to connect the VIM with these information. After authentic succeed(that is to say the VIM is reachable), then ESR store these VIM information to A&AI, do heartbeat detection for VIM status and store the system status. So that other components can determine whether the system is available based on the status.

  2. ONAP Portal provides an SDK to develop portals so that we have consistent authentication and common functions across ONAP. Have you check it out?

    Also if this is a subproject of A&AI, it does not seem that way from the functional architecture


    1. Yes, we will fix our seed code to support the consistent authentication based on the Portal SDK