Hi TSC members,
Just like what described in the ESR propsal. 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. For the proposal
detail please visit https://wiki.onap.org/pages/viewpage.action?pageId=5734948
There is something I want to elaberate before the ESR discussion meeting next
week.
After I proposed the proposal of ESR in ONAP to be a independent project.
Mazin/Catherine/Stephen and Jacopo suggested that ESR should be combined with
A&AI. Our team discussed this with A&AI team several time during and after the
F2F meeting in Beijing. And the A&AI team also agreed ESR to be a subproject of
A&AI before last TSC meeting, and Jimmy(the PTL of A&AI) also add the
committers of ESR to join the PTL polling of A&AI. But after a better
understanding of ESR, Jimmy think that ESR is not relevant to A&AI and A&AI is
just the data storage backend of ESR.
According to the suggestion of Stephen, a table was scheduled to discuss about
how the ONAP components will be provisioned with external addresses. After
discussed with each project (by ESR discussion meeting or email or phone call)
, we come to a conclusion what seen at the table bellow. From the table we can
read that the function of ESR is necessery. For the discussion record please
visit https://wiki.onap.org/display/DW/ESR+Discussion+And+Comments+Collection
After discussed with our team members, we think that DCAE could be a consummer
of ESR, just like Multi-VIM and VF-C.
If you have any suggestion about which project ESR should belongs to, please
tell me. And we can invite the related folks to discuss this problem at the ESR
meeting next week. If there is no project in ONAP that ESR fits for, I hope the
TSC members could approve that ESR to be a independent project.
Scenario
External system to be provisioned
Baseline approach
Reflections Have Interface Interact With ESRProject PTLFeedback FromConnection
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
lixinhui
lixinhui
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
Amichai Hemli
Avi from amdocs ([email protected])VF-C: get the VIM addresses from ESR.
Yes
Yan Yang
Yan Yang
maopeng zhang
SO: will not interact with external system directly
No
Seshu Kumar M
jin xinConnection 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
Dan Timoney
Connecting to S-VNFM
S-VNFM and capabilites
VF-C: manage VNFM addresses from ESRCould be part of the tosca/heat
templateYes
Yan Yang
Yan Yang
maopeng zhang
EMS
(Element Management System)
EMS address and capabilitiesAPP-C: will not interact with external system
directly. Interfaces with other ONAP Components: AAI, Policy,, MSO, DCAE etc.
No
Randa Maher
Catherine LefevreOther
DCAE: DCAE will not collect the data from external system？
Lusheng Ji
Best Regards,
LiZi
_______________________________________________
onap-discuss mailing list
[email protected]
https://lists.onap.org/mailman/listinfo/onap-discuss
