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 infrastructure site/location/region and their attributes and capabilities in A&AI, including compute, storage, networking (including local and vendor SDN controllers) etc./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: Integration with multi VIMs via Multi-VIM. | SO: ? | get the VIM addresses from ESR. | Yes | |||
| SO: will not interact with 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? | Yes | |||
Connecting to S-VNFM | S-VNFM and capabilites | VF-C: query S-manage VNFM addresses from ESR | Could be part of the tosca/heat template | Lingli DengYes | ||
EMS (Element Management System) | EMS address and capabilities | APP-C: ?: will not interact with EMS directly. 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 |
| View file | ||||
|---|---|---|---|---|
|
Stephen:
Based on the above, I understand that the Functionality that ESR provides is to enable a common means to input the addressing information required to enable ONAP to contact these external systems. That functionality does seem like a good idea. If we turn our attention to what is required, this seems to required:
- A means to input the addressing information
- A place to store the addressing information
- A means for the ONAP modules to retrieve this information.
A assume the means to input the addressing information should be using the SDC environment, I mean it isn't optimal to have another creation environment with a different look and feel.
Part of the discussion as I understand is to store this information into A&AI, actually it is kind of static inventory information - is this a decent fit - it could be better than having yet another storage to deal with.
If the above was correct, then I guess that ESR somewhat becomes a proxy for the address information, is that required or could that be directly retrieved from the storage instead, and the ESR project focusses on creating the module required in SDC to input the data and place it in the storage instead of having a proxy?
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
RE: Stephen
Actually, SDC has nothing to do with ESR. SDC runs at the design time, while ESR runs at the run time. ESR provide a portal for user to input the external system address information.
The data stored to A&AI from ESR included the addresses information and the status of external system. In my opinion, it is just like the instance data stored in A&AI.
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 )
ONAP Meeting 7 is inviting you to a scheduled Zoom meeting.
Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/434830725
Or iPhone one-tap (US Toll): +16465588656,,434830725# or +14086380968,,434830725#
Or Telephone:
Dial: +1 646 558 8656 (US Toll) or +1 408 638 0968 (US Toll)
+1 855 880 1246 (US Toll Free)
+1 877 369 0926 (US Toll Free)
Meeting ID: 434 830 725
International numbers available: https://zoom.us/zoomconference?m=Va3Jg8p0-BZUnCV0JLW90sn3ozepN21M
Attached is the comments about ESR:
...
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.
...