The table bellow describes the problem and how it is or isn’t addressed today
Scenario | External system to be provisioned | Baseline approach | Reflections | Have Interface Interact With ESR | Project PTL | Feedback From | |
|---|---|---|---|---|---|---|---|
Connection to cloud infra | Address and capabilities of VIM managers (e.g. openstack port) | Mult-VIM: will register/unregister VIM with ESR, the register VIM from ESR portal and need the health check function of VIM. | Yes | ||||
| VID: manually input the VIM addresses and connection information to the portal, and sent this info to MSO which later call controllers which interact with all of these systems (VNFMS , VIM , EMS) | No | Avi from amdocs (avi.chapnic@amdocs.com) | |||||
| VF-C: get the VIM addresses from ESR. | Yes | ||||||
| SO: will not interact with external system VIM directly | No | jin xin | |||||
Connection to transport | SDN controller address’s and capabilities | vendor sdn controler which managed by VIM is not in the scope of ESR. How about the vendor sdn controller managed by ONAP SDN-C? There is a request about API used to verify that platform is available from SDN-C release plan. ONAP SDN-C: ? | no response ONAP SDN-C: For SDN-C, we are considering use of ESR for managing credentials with external SDN controllers as a "stretch goal" for release 1. Ultimately we do see a benefit to using ESR, but if we find that we cannot do so in release 1 without jeopardizing our dates, then we would just use local properties files for release 1 (as we did in our seed code) and integrate with ESR in a later release. | Yes | |||
Connecting to S-VNFM | S-VNFM and capabilites | VF-C: manage VNFM addresses from ESR | Could be part of the tosca/heat template | Yes | |||
EMS (Element Management System) | EMS address and capabilities | APP-C: will not interact with external system EMS directly. Interfaces Only have interfaces with other ONAP Components: AAI, Policy,SDC, MSO, DCAE etc. | No | cl664y@att.com | |||
| VF-C: manage EMS addresses from ESR | Yes | ||||||
| Other | DCAE: DCAE will not collect the data from external system? | Lusheng Ji |
...
We have reached an agreement with Jimmy(the PTL of A&AI) that ESR team will be committed to working the necessary A&AI features and interface agreements to support making A&AI the datastore for ESR data. The portal and update functions can be a separate microservice and would use A&AI as the database.
ESR meeting information
Time: wednesday(9 PM China, 1 PM UTC, 9 AM US/Eastern, 5th July )
...
ESR will supplies both portal and API to manage(register/query/delete/update) the external system, but will not deploy the external system. (Here external system means that the systems already exsist somewhere, but not included in ONAP, such as VIM/VNFM/EMS/vendor SDN controller)
ESR will check whether the external systems are reachable, but will not do the fault analysis.
...
The Provider Registry in the Multi-VIM will register infrastructure site/location/region and their attributes and capabilities in A&AI, including compute, storage, networking (including local and vendor SDN controllers) etc.
See https://wikilf-onap.onapatlassian.orgnet/wiki/pages/viewpage.action?pageId=324726216224047
So we have an interface to A&AI for registration.
...