Hi, All,
To make a clearer description about merge plan 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&AIProvide the Portal
for user to register/query/update/delete external systema function of ESR
which would be a sub-project of A&AIcheck 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
And also the baseline approach of each project to got the external system
addresses in different scenario shows as the table bellow:
Scenario
External system to be provisioned
Baseline approach
Reflections Have Interface Interact With ESRConnection to cloud infra
Address and capabilities of VIM managers
(e.g. openstack port)
Mult-VIM: will register/unregister VIM with ESR/A&AI, the register VIM from ESR
portal and need the health check function of VIM.
YesVID: 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)
NoVF-C: get the VIM addresses from ESR/A&AI.
YesSO: will not interact with external system directly
NoConnection 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 responseConnecting to S-VNFM
S-VNFM and capabilites
VF-C: manage VNFM addresses from ESR/A&AICould be part of the tosca/heat
templateYesEMS
(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.
NoVF-C: manage EMS addresses from ESR/A&AI
YesOther
DCAE: DCAE will not collect the data from external system?
Hope it helps for your judgement.
Thanks,
Li Zi
原始邮件
发件人：李滋00164331
收件人： <[email protected]>
抄送人： <[email protected]> <[email protected]>
<[email protected]>
日 期 ：2017年07月10日 15:54
主 题 ：RE: RE: [onap-discuss] ESR
Hi, Dear TSC members,
As we discussed with the PTL of related project, ESR is necessary for Amsterdam
release. Also our team has got a consensus that ESR team is 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. And Jimmy (A&AI PTL)
agreed that the Portal/healthcheck function of ESR to be the subproject of A&AI.
So, Could I suggest that the TSC cast a vote for ESR?
For ESR proposal https://wiki.onap.org/pages/viewpage.action?pageId=5734948
For ESR discussion result
https://wiki.onap.org/display/DW/ESR+Discussion+And+Comments+Collection
Thanks,
Li Zi
发件人： <[email protected]>
收件人：李滋00164331 <[email protected]> <[email protected]>
<[email protected]>
日 期 ：2017年07月07日 21:38
主 题 ：RE: [onap-discuss] ESR
Hi, Everyone,
After further discussion with Li Zi, I believe that from the perspective of
development resources, A&AI might be the best choice as the parent project for
ESR even if typically A&AI does not do the kind of UI and healthcheck function
that ESR provides. Li Zi’s team is 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.
Therefore, if the TSC agrees that the ESR data is necessary and useful in the
Amsterdam release, ESR can stay with A&AI for this release. If there is
consensus that the portal healthcheck/creation/management GUI belongs outside
A&AI perhaps that microservice could be moved at some point, but given that Li
Zi’s team is committed to manage that piece I believe A&AI can accommodate this
sub project for Amsterdam.
Thanks,
Jimmy Forsyth
From: [email protected]
[mailto:[email protected]] On Behalf Of [email protected]
Sent: Friday, July 07, 2017 8:13 AM
To: [email protected] GILBERT, MAZIN E <[email protected]>
[email protected]
Subject: [onap-discuss] ESR
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.
1. 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.
2. 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
3. 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 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
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 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
Dan Timoney
Connecting to S-VNFM
S-VNFM and capabilites
VF-C: manage VNFM addresses from ESR
Could be part of the tosca/heat template
Yes
Yan Yang
Yan Yang
maopeng zhang
EMS
(Element Management System)
EMS address and capabilities
APP-C: will not interact with external system directly. Interfaces with other
ONAP Components: AAI, Policy,, MSO, DCAE etc.
No
Randa Maher
Catherine Lefevre
Other
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
