Just to highlight the current architecture in the seed code. There is the portal (which has a project). It’s the framework for all GUI’s in the seed code. All GUI’s in the seed code are applications which plug into the portal. This allows for a common authorization/authentication, looks and feel etc… . So there is only ONE GUI and VID is an app plugging into it.
From experience this kind of architecture is preferred over a single portal code base including all possible applications as that code base would quickly become the bottleneck in development and above allows for a simple divide and conquer approach. So the use case UIs (whichever we might need) should also be applications on that portal framework and not a stand alone GUI as we all agree we only want ONE. As for VID in particular. In the seed code VID’s intended role is managing infrastructure deployment (virtual infrastructure deployment == VID). It doesn’t manage customer service facing VNFs. In a production setting we don’t have a GUI for those. The management of those are triggered directly as part of our BSS systems via API call not through a separate GUI. For the demo in the seed code we ended up using VID for the demo VNFs as our BSS systems are not part of ONAP and we needed some sort of GUI. So this was more a hack to have a reasonable demo then an architectural choice. Oliver On Jun 5, 2017, at 2:56 AM, shentao <[email protected]<mailto:[email protected]>> wrote: Dear Gaurav There are several projects which have portal functions, but some necessary functions don’t be provided by any project. (alarm monitor, show performance, end-user self-service, etc.) I suggest that we’d better to generalize all portals and implement functions that not exist or not intend to provided in Usecase UI project. Best regards, Shentao 发件人: Gaurav Gupta (c) [mailto:[email protected]] 发送时间: 2017年6月5日 14:18 收件人: shentao; 'Dhananjay Pavgi'; 'ROSE, DANIEL V'; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; 'HEMLI, AMICHAI'; 'ANAPAN-LAVALLE, HECTOR A' 抄送: [email protected]<mailto:[email protected]> 主题: Re: [onap-discuss] Question on VID Dear shentao and all Does it make sense to put this Usecase UI Project discussion to TSC/architecture forum . with best regards gaurav ________________________________ From: shentao <[email protected]<mailto:[email protected]>> Sent: 05 June 2017 08:06:23 To: 'Dhananjay Pavgi'; Gaurav Gupta (c); 'ROSE, DANIEL V'; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; 'HEMLI, AMICHAI'; 'ANAPAN-LAVALLE, HECTOR A' Cc: [email protected]<mailto:[email protected]> Subject: 答复: [onap-discuss] Question on VID Dear all I’m going to build Usecase UI project to solve this problem. I’ve listed all portal requirements of ONAP in Usecase UI Proposal. And suggest portal functions which have not be implemented should build in this project. The project proposal described specific fuctions. (https://wiki.onap.org/display/DW/Usecase+UI+Proposal+Template<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_display_DW_Usecase-2BUI-2BProposal-2BTemplate&d=DwMFbw&c=LFYZ-o9_HUMeMTSQicvjIg&r=9iyuArzgyekj47PZSPfIijI2cSHsUJtAlcTA0X_udNI&m=sqGmJr54H9guOXqRpHLOgj1XPdbi5VrOrO-SBcMTUdM&s=h473OiBP-E-0CeXfzzxcxlE0Zfu_37Gi2r9yxjYXHoc&e=>) Usecase UI will provide GUI for operators and end-users from the point of view of use cases. As a whole project, Usecase UI requiremetns not only includes service design and run-time management (resource, performance, fault, security, configuration, etc.) for operators, but also includes self-service management for end-users. This project targets identifying all GUI requirements which operators and end-users need ONAP to support, coordinating GUI parts of each ONAP subsystem, filling the gaps for improving GUI functionalities for use case. All GUI functionalities of ONAP system can be well showed to satisfy the requirements from different customers. Scope: 1. The Designer Role: • Service design (implemented by SDC) • VNF onboarding (implemented by SDC) • Policy design (implemented by Policy Framework) • Closed Loop design (implemented by CLAMP) 2. The Operator Role: • Service LCM (implemented by VID portal) • Inventory for services and resources (implemented by A&AI) • Monitor system alarms (implemented by this project) • Alarm correlation (implemented by Holmes) • Show system performance (implemented by this project) 3. The user Role: (Implemented by this project) • Provide model-based vCPE instance orchestration interface • Consume and interpret standard ONAP vCPE models • Call service orchestration systems to configure services and VNFs in the core and at the edge • Use inventory systesm to determine currently defined inventory for core and edge services • End-user self-service management UI of provisioned vCPE elements Best regards, Shentao 发件人: Dhananjay Pavgi [mailto:[email protected]] 发送时间: 2017年6月4日 19:05 收件人: Gaurav Gupta (c); ROSE, DANIEL V; shentao; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; HEMLI, AMICHAI; ANAPAN-LAVALLE, HECTOR A 抄送: [email protected]<mailto:[email protected]> 主题: RE: [onap-discuss] Question on VID Very valid point, Gaurav. ONAP has multiple GUIs and take this as a request to TSC/community members to arrive at role definition for each GUI to ensure that there’s no ambiguity and the same role calling to use more than one GUI. If there’s such overlaps then we should get those sorted. thanks & regards, Dhananjay Pavgi Mobile : +91 98220 22264 <image001.png> <image002.jpg> www.techmahindra.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.techmahindra.com_&d=DwMFbw&c=uilaK90D4TOVoH58JNXRgQ&r=ebJjFMpXijqZjbZCcbF7yJIq2ES6jM0Q-DEcP-qjjeI&m=h6XsWTqslUjGxabTAUQH--_6xnoJwBMQFvXHHcPlpXU&s=bU_0iEilOxf_jHhIrg5CYfM5v3z-9c6vGrwpnZior-I&e=> Platinum Member. Visit : http://www.onap.org<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.onap.org_&d=DwMFbw&c=uilaK90D4TOVoH58JNXRgQ&r=ebJjFMpXijqZjbZCcbF7yJIq2ES6jM0Q-DEcP-qjjeI&m=h6XsWTqslUjGxabTAUQH--_6xnoJwBMQFvXHHcPlpXU&s=7iiIeCsI8GsZlJAf_a0Fegh1QgAypMbiOxqaJUgjOuc&e=> From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Gaurav Gupta (c) Sent: Saturday, June 03, 2017 9:07 AM To: ROSE, DANIEL V <[email protected]<mailto:[email protected]>>; shentao <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; HEMLI, AMICHAI <[email protected]<mailto:[email protected]>>; ANAPAN-LAVALLE, HECTOR A <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> Subject: Re: [onap-discuss] Question on VID Daniel Rose I assumed that one of the Goal of ONAP is managing the Cloud Infra and Service easy for the Telco Operator . As in traditional/conventional Network infra environment Network Element had their own EMS/NMS System and even if some functions of NE or all of the NE even if virtualized , poses a problem for the operator to look at 2 Screen at least . a- EMS/NMS for NE and Service/KPI/Network Health Monitoring b- Another for monitoring the health of Virtualized environment Do you think - having too many GUI's would causes a lot of overhead unless you are thinking of restricting each GUI to a specific Role . Do correct if I am missing something subtle . with best regards gaurav ________________________________ From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> on behalf of ROSE, DANIEL V <[email protected]<mailto:[email protected]>> Sent: 02 June 2017 22:52 To: shentao; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; HEMLI, AMICHAI; ANAPAN-LAVALLE, HECTOR A Cc: [email protected]<mailto:[email protected]> Subject: Re: [onap-discuss] Question on VID Hector do you know what kind of gui we have and where it is now? Thanks, Daniel Rose ECOMP / ONAP com.att.ecomp 732-420-7308 From: shentao [mailto:[email protected]] Sent: Friday, June 02, 2017 5:09 AM To: ROSE, DANIEL V <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; HEMLI, AMICHAI <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> Subject: 答复: [onap-discuss] Question on VID Hi, Daniel Thanks for your reply. I’m working to summarize portal requirements and want to confirm if VID is going to provide a portal for service LCM because it seems no description about GUI in VID proposal. If VID provides a portal for service LCM, I agree with you that there is no necessary to build the same part in Usecase UI project. Btw, as I understand appc provides NB APIs, but not gui. Does service lifecycle gui not exist in VID gui? Best regards, Shentao 发件人: ROSE, DANIEL V [mailto:[email protected]] 发送时间: 2017年5月31日 4:14 收件人: shentao; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; HEMLI, AMICHAI 抄送: [email protected]<mailto:[email protected]> 主题: RE: [onap-discuss] Question on VID On the one hand, VID already has a portal integration. To answer your questions in a more broad way I don’t think we want to go about creating GUIs for each specific use case (but I guess if the community does they can reply and keep me honest) and that is what I got as the output from a read of your project proposal. The idea in my opinion is to add capabilities to the platform. When you look at it that way I see 3 gui areas Service Design, Service Instantiation and Service Lifecycle. Service design is already covered by sdc and that project. Service Instantiation is covered by VID and service lifecycle is covered by appc gui, which may or may not be open sourced right now I am not sure but I am sure we would be ok with doing so if its not. Then if the release 1 use cases need enhancements t that we should implement them generically and any vnf can use it. I certainly don’t want to build the same thing for vcpe and volte! Either way I don’t know what exactly your project is looking to do. Can you clarify your project proposal a bit so vi d can better work together with you? Thanks, Daniel Rose ECOMP / ONAP com.att.ecomp 732-420-7308 From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of shentao Sent: Tuesday, May 30, 2017 3:52 PM To: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; HEMLI, AMICHAI <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> Subject: [onap-discuss] Question on VID Hi, Michael and Helmi I’m working for UseCase UI project and found that there is a relationship between UseCase UI and VID project. I’ve looked through the VID proposal and have some questions about VID project. Could you help me to confirm questions about VID project. Thank you very much. 1. Is VID project planning to provide a portal component which will integrate into Portal Platform? 2. If VID project provides a portal component, what detail functions will be provided? UseCase UI project will support managements of service & VNF lifecycle, I don’t know whether VID has a duplicate scope because there is service & VNF description in VID scope. 3. In UseCase UI proposal, seed code is linking to VID’s repo (https://gerrit.onap.org/r/#/admin/projects/vid<https://urldefense.proofpoint.com/v2/url?u=https-3A__gerrit.onap.org_r_-23_admin_projects_vid&d=DwMFbw&c=LFYZ-o9_HUMeMTSQicvjIg&r=2wwdGZ3YcpSivQ2Kio028A&m=s_pnutB5B1kDdiy98MfuTyx1YYlN1nrqG9i5z1LqUdA&s=tek-4tg2eYSYZLZvjfjE7XVCYwz7CRpJTeTU5YsvVrw&e=>). Does it mean that VID repo is currently including seed code of UseCase UI (vCPE or VoLTE)? This involves question2 that I don’t know why UseCase UI’s seed code is in VID’s repo. Best regards, Tao Shen --------------------------------------------- 沈涛 中国移动通信有限公司研究院网络技术研究所 中国北京市西城区宣武门西大街32号（100053） Shen Tao China Mobile Research Institute No.32 Xuanwumen west street,Xicheng District, Beijing 100053, China Tel: +86 15801696688-34070 Mobile: +86 13521591389 Email: [email protected]<mailto:[email protected]> --------------------------------------------- ============================================================================================================================ Disclaimer: This message and the information contained herein is proprietary and confidential and subject to the Tech Mahindra policy statement, you may review the policy at http://www.techmahindra.com/Disclaimer.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.techmahindra.com_Disclaimer.html&d=DwMFbw&c=uilaK90D4TOVoH58JNXRgQ&r=ebJjFMpXijqZjbZCcbF7yJIq2ES6jM0Q-DEcP-qjjeI&m=h6XsWTqslUjGxabTAUQH--_6xnoJwBMQFvXHHcPlpXU&s=U9qJhOagXP2PIM0PKOHVYZbp9wjazz6RBTVTMm-9OlM&e=> externally http://tim.techmahindra.com/tim/disclaimer.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__tim.techmahindra.com_tim_disclaimer.html&d=DwMFbw&c=uilaK90D4TOVoH58JNXRgQ&r=ebJjFMpXijqZjbZCcbF7yJIq2ES6jM0Q-DEcP-qjjeI&m=h6XsWTqslUjGxabTAUQH--_6xnoJwBMQFvXHHcPlpXU&s=OKRQiUp5JyhhREYjbHREM1WE7MVaAJ458GBpU26aowY&e=> internally within TechMahindra. ============================================================================================================================ _______________________________________________ onap-discuss mailing list [email protected]<mailto:[email protected]> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Ddiscuss&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=9iyuArzgyekj47PZSPfIijI2cSHsUJtAlcTA0X_udNI&m=sqGmJr54H9guOXqRpHLOgj1XPdbi5VrOrO-SBcMTUdM&s=Akl8sJHsjAdngcGUBReE5bLSlH1HGAugkQZT2MBpsqo&e=
_______________________________________________ onap-discuss mailing list [email protected] https://lists.onap.org/mailman/listinfo/onap-discuss
