Hi Li, I will gladly add it to the agenda but be advised the TCS calendar is very full this week.
Best Regards, -kenny Kenny Paul, Technical Program Manager [email protected] 510.766.5945 > On Jul 12, 2017, at 2:04 AM, [email protected] wrote: > > > > Hi Kenny, > > > > Could you please add an agenda of External System Register review for the TSC > meeting on Thursday this week? > > > > Thanks, > > Li Zi > > > > > > > > 原始邮件 > 发件人：李滋00164331 > 收件人： <[email protected]>; <[email protected]>; > <[email protected]>; <[email protected]>; > <[email protected]>; <[email protected]>; > 抄送人： <[email protected]>; <[email protected]>; > 日 期 ：2017年07月11日 10:10 > 主 题 ：[onap-discuss] [esr] [aai] Hope to add an agenda for ESR at TSC meeting > for this week > > > Hi all, > > > > Since A&AI team and ESR team have made a consensus about the merge approach. > I would like to suggest to cancel the ESR discussion meeting for this week > (planned at last TSC meeting) and add an agenda for ESR review at the TSC > meeting (13th July ). How do you think about this ? > > If you have any question about ESR please let me know. > > > > Thanks, > > Li Zi > > > > > > > > > > > > 发件人：李滋00164331 > 收件人： <[email protected]>; <[email protected]>; > <[email protected]>; <[email protected]>; > 抄送人： <[email protected]>; <[email protected]>; > 日 期 ：2017年07月10日 18:05 > 主 题 ：Re: [onap-discuss] ESR > > > 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-end contribute these function to A&AI > Provide the Portal for user to register/query/update/delete external system > a 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&AI > a 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 ESR > Connection 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. > 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 > VF-C: get the VIM addresses from ESR/A&AI. > Yes > SO: will not interact with external system directly > No > 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 > Connecting to S-VNFM > > S-VNFM and capabilites > > VF-C: manage VNFM addresses from ESR/A&AI 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 > directly. Interfaces with other ONAP Components: AAI, Policy, MSO, DCAE etc. > > No > VF-C: manage EMS addresses from ESR/A&AI > Yes > Other > 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 > <https://wiki.onap.org/pages/viewpage.action?pageId=5734948> > > For ESR discussion result > https://wiki.onap.org/display/DW/ESR+Discussion+And+Comments+Collection > <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 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_pages_viewpage.action-3FpageId-3D5734948&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=Oej6QUk5p2KdqNEWySpOHA&m=Uss29O7va1vcBfVwUFjXKERSOmo4BaJOostN5Bs3YHg&s=MVsHf8pg6wk23K_amIJW6s1MY_rwHSJRV9wWTpr7HLY&e=> > > > 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 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_display_DW_ESR-2BDiscussion-2BAnd-2BComments-2BCollection&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=Oej6QUk5p2KdqNEWySpOHA&m=Uss29O7va1vcBfVwUFjXKERSOmo4BaJOostN5Bs3YHg&s=YvcnGUEn-v_7IGgA6M2CVXgSlBClyJrX7WTBknQsbbg&e=> > > > 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 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_display_-7Exinhuili&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=Oej6QUk5p2KdqNEWySpOHA&m=Uss29O7va1vcBfVwUFjXKERSOmo4BaJOostN5Bs3YHg&s=WnOLNU2yBLjTd_84yTSfRUiD_pfOW_IVvRiGLEz3TAI&e=> > > lixinhui > <https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_display_-7Exinhuili&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=Oej6QUk5p2KdqNEWySpOHA&m=Uss29O7va1vcBfVwUFjXKERSOmo4BaJOostN5Bs3YHg&s=WnOLNU2yBLjTd_84yTSfRUiD_pfOW_IVvRiGLEz3TAI&e=> > 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 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_display_-7Eahemli&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=Oej6QUk5p2KdqNEWySpOHA&m=Uss29O7va1vcBfVwUFjXKERSOmo4BaJOostN5Bs3YHg&s=w-xUtV-FtRQosaZifC5cWwepZN01FLEmCSPC6SVhX9k&e=> > > Avi from amdocs ([email protected] <mailto:[email protected]>) > > VF-C: get the VIM addresses from ESR. > > > Yes > > Yan Yang > <https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_display_-7Eyangyan&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=Oej6QUk5p2KdqNEWySpOHA&m=Uss29O7va1vcBfVwUFjXKERSOmo4BaJOostN5Bs3YHg&s=nw9Dh-gTQZ26R_ztq3DAafUKz3PwKmX1_1wHVzmW1PU&e=> > > Yan Yang > <https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_display_-7Eyangyan&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=Oej6QUk5p2KdqNEWySpOHA&m=Uss29O7va1vcBfVwUFjXKERSOmo4BaJOostN5Bs3YHg&s=nw9Dh-gTQZ26R_ztq3DAafUKz3PwKmX1_1wHVzmW1PU&e=> > maopeng zhang > <https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_display_-7Emaopengzhang&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=Oej6QUk5p2KdqNEWySpOHA&m=Uss29O7va1vcBfVwUFjXKERSOmo4BaJOostN5Bs3YHg&s=A-HR6anqCguTHbVAQxV7EilnkS9YMeFkJNWA1kglPzc&e=> > SO: will not interact with external system directly > > > No > > Seshu Kumar M > <https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_display_-7Eseshukm&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=Oej6QUk5p2KdqNEWySpOHA&m=Uss29O7va1vcBfVwUFjXKERSOmo4BaJOostN5Bs3YHg&s=_Q_b6acWgC_EwR57enKN_EBszDqeqzyHX_EPzPbILRc&e=> > > jin xin > <https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_display_-7Ejinxin1983&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=Oej6QUk5p2KdqNEWySpOHA&m=Uss29O7va1vcBfVwUFjXKERSOmo4BaJOostN5Bs3YHg&s=qC8jfMQ-7svDp6OY9onFuXd7jNS8QxNOsw0H0U7S7Dk&e=> > 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 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_display_-7Edjtimoney&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=Oej6QUk5p2KdqNEWySpOHA&m=Uss29O7va1vcBfVwUFjXKERSOmo4BaJOostN5Bs3YHg&s=ZdphNQippVQ2Bxb8EkC7koilXdxOfoDw_QZcIzJ1g-g&e=> > > 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 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_display_-7Eyangyan&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=Oej6QUk5p2KdqNEWySpOHA&m=Uss29O7va1vcBfVwUFjXKERSOmo4BaJOostN5Bs3YHg&s=nw9Dh-gTQZ26R_ztq3DAafUKz3PwKmX1_1wHVzmW1PU&e=> > > Yan Yang > <https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_display_-7Eyangyan&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=Oej6QUk5p2KdqNEWySpOHA&m=Uss29O7va1vcBfVwUFjXKERSOmo4BaJOostN5Bs3YHg&s=nw9Dh-gTQZ26R_ztq3DAafUKz3PwKmX1_1wHVzmW1PU&e=> > maopeng zhang > <https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_display_-7Emaopengzhang&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=Oej6QUk5p2KdqNEWySpOHA&m=Uss29O7va1vcBfVwUFjXKERSOmo4BaJOostN5Bs3YHg&s=A-HR6anqCguTHbVAQxV7EilnkS9YMeFkJNWA1kglPzc&e=> > 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 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_display_-7Erx196w&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=Oej6QUk5p2KdqNEWySpOHA&m=Uss29O7va1vcBfVwUFjXKERSOmo4BaJOostN5Bs3YHg&s=8S1RpVEyoIAUbc8mkUZvRtrqKWrJa1MaP7hqNbsymd4&e=> > > Catherine Lefevre > <https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_display_-7EKatel34&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=Oej6QUk5p2KdqNEWySpOHA&m=Uss29O7va1vcBfVwUFjXKERSOmo4BaJOostN5Bs3YHg&s=Y-ILLctv3A3SYISUU57aP3qyQ9MtALMdn3h1gOeb1LA&e=> > Other > > > DCAE: DCAE will not collect the data from external system？ > > > > Lusheng Ji > <https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_display_-7Ewrider&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=Oej6QUk5p2KdqNEWySpOHA&m=Uss29O7va1vcBfVwUFjXKERSOmo4BaJOostN5Bs3YHg&s=nEVt72taywbJHL7qWPovFm1F8HkHsJESpuDziygg2W8&e=> > > > > Best Regards, > LiZi > > > > > > > > > > >
_______________________________________________ onap-discuss mailing list [email protected] https://lists.onap.org/mailman/listinfo/onap-discuss
