Yuan, just to be clear we did agree to integrate Holmes into DCAE in release 1.0: "DCAE supports Holmes to be deployed as an analytic application in the form of docker(s)."
As for which use case is using which configuration this will have to be decided as part of the release planing I presume. Thx Oliver > On Jun 13, 2017, at 10:29 AM EDT, yuan....@zte.com.cn wrote: > > Hi Mazin, > > > > I believe the Holmes team have deelply discussed with DCAE team off line and > in line during Beijing F2F meeting. Holmes team totally understood DCAE team > is proposing DCAE framework with perfect architecture and will be implemented > step by step. In release 1, Holmes will work independently to support close > loop for voLTE use case and Holmes team will keep in touch with DCAE team for > future integration. Keeping aligment in interface level but decouple the > components with each other would be better for open source practice. Let end > users make decision how they would like to integrating different components > in different scenarios. > > > > Regards, > > Yuan Yue > > > > > > > > 袁越 yuanyue > > 资深战略规划师 Senior Strategy Planner > > 技术规划部/技术规划部/系统产品 Technology Planning Dept./Technology Planning Dept./System > Product > > > > > <9ae3e214c17d49ed935d87c674ba3ee2.jpg> > <24242e5637af428891c4db731e7765ad.jpg> > 南京市雨花区软件大道50号中兴通讯3号楼 > 1/F,Building 3, ZTE Nanjing R&D Center II, No.50, Software Avenue,YuHua > District,Nanjing,P.R.China 210012 > T: +025 88013478 > M: +86 13851446442 > E: yuan....@zte.com.cn > www.zte.com.cn > 原始邮件 > 发件人： <ma...@research.att.com>; > 收件人：付光荣10144542; > 抄送人： <t...@lists.onap.org>; <onap-tsc@lists.onap.org>; > 日 期 ：2017年06月13日 04:45 > 主 题 ：Re: [onap-tsc] Forward:Re: Comments about Holmes > > > Ok. It would have been beneficial to have a deeper dive with the DCAE team > and the architecture team so you understand the flow and architecture. > My view is not to allow this to run independently. They are serious efforts > in terms of life cycle management, resource management, > reliability, etc that one needs to support for each of these components, and > we can not repeat that work for each analytics service > provided by each contributor. > > Hence DCAE tries to bring it all together and enable on boarding of different > types of Microservices. > > >> On Jun 11, 2017, at 11:18 PM, fu.guangr...@zte.com.cn wrote: >> >> Hi Mazin, >> >> We have discussed with Oliver and are now aware of that DCAE is an open >> platform that allows independent/external systems to be integrated with it. >> Based on this and to make Holmes more flexible, we proposed Holmes to be set >> up as a standalone project. >> >> Being a standalone project does not mean that Holmes will not support DCAE. >> Holmes will expose DMaaP related APIs to the public and be released in the >> form of docker(s) so that it can be integrated with DCAE. Meanwhile, as an >> independent system, Holmes can also be run in standalone mode, which >> enables it to be connected or utilized by other systems in ONAP directly. >> >> Regards, >> >> Guangrong >> >> >> >> > > > > > 发件人：zhaohuabing10201488 > 收件人：fuguangrong10144542; > 抄送人：mengzhaoxing10024238;wangrui10208678; > 日 期 ：2017/06/12 09:05 > 主 题 ：Forward：Re: [onap-tsc] Comments about Holmes > > From: GILBERT,MAZINE(MAZINE); > To:roberto.k...@orange.com; fuguangrong10144542; > Cc:t...@lists.onap.org; > Date: 2017-06-11 06:08:46 > Subject:Re: [onap-tsc] Comments about Holmes > > > Guangdong > > > I realize the TSC arrived at a middle ground during the F2F meeting of having > Holmes as a separate project. I have tried to share my views on this > previously and it seems to have failed. DCAE is a framework for on operating > big data Microservices. Holmes is an analytics Microservice, that is policy > driven. The policies are set through Drools by the Policy engine, while the > analytics is done by DCAE. DCAE and Policy have well defined protocols to > help operate control loops. This design was done so that developers can > build, test and deploy their own Microservices (correlations, predictions,, > normalization, compressions, analytics, etc) without having to establish yet > another independent component in ONAP. There are numerous large-scale > correlation engines adopted by many operators and vendors today. Holmes is > one example. This flexibility in the design in ONAP. allows companies to plug > and play their Microservices function without additional dependencies or > software development. This approach is successful and how it is employed in > AT&T. > > > > I strongly suggest you spend sometime to better understand how DCAE and > open/close loops work in ONAP. It is very important that we enable > disaggregation and flexibility so that developers can innovative quickly. I > will rely heavily on the architecture subcommittee to ensure Holmes is > properly disaggregated when used in ONAP. > > > Thanks and look forward to your contributions to R1. > > > Mazin > > > > Get Outlook for iOS > _____________________________ > From: roberto.k...@orange.com > Sent: Wednesday, June 7, 2017 11:29 AM > Subject: Re: [onap-tsc] Comments about Holmes > To: < fu.guangr...@zte.com.cn> > Cc: < t...@lists.onap.org> > > > > Thanks for your comments. This will be discussed and decided at the TSC. Best > regard. Roberto > > > De : fu.guangr...@zte.com.cn [mailto:fu.guangr...@zte.com.cn] > Envoyé : mercredi 7 juin 2017 16:42 > À : KUNG Roberto OLN/QOP > Cc : t...@lists.onap.org > Objet : 答复: Comments about Holmes > > > Hi Roberto, > > > Thanks for your information. > > > For the overlap, I have to clarify again that although Holmes and Policy are > both based on Drools, the goal of them is totally different. Holmes is > targeted to find out the correlation among tens of thousands (even more) of > alarms while Policy is aimed to which action should be taken to accomplish > auto-scaling/auto-healing tasks. I think systems should be defined by what > their functions rather than the technologies they adopt. > > > Besides, to make our systems easier to maintain, we have to hold on to the > Single Responsibility Principle. If we merge Holmes with Policy, the logic of > the policy rules will get much more complicated, which makes it rather hard > to trace or fix the problem/bug if any occurs in the futher. > > > For the reasons above, I still suggest we make Holmes an independent project > in ONAP. > > > Guangrong > > > > > > 原始邮件 > > 发件人：＜roberto.k...@orange.com＞; > > 收件人：付光荣10144542; > > 抄送人：＜t...@lists.onap.org＞; > > 日期 ：2017年06月07日 04:17 > > 主题 ：Comments about Holmes > > > https://wiki.onap.org/display/DW/Initial+Project+Proposal+Feedback+From+the+TSC. > I have seen that you have taken into account our feedback. I have provided > a summary below. > > > · Clarity: Project description and scope are clear. > > · Overlap: It is felt that the project should be split and combine > with DCAE (for the correlation engine), Policy engine (for Drools), and CLAMP > (for designing the open loop). > > · Risk management: this addition to other projects should be > discussed with other projects with the objective to add mature/production > level code in R1, or could be targeted to subsequent Rs if delivery may be > felt difficult > > · Relevance and prioritization: this is relevant to the ONAP release. > > > I hope this will help with your preparations for next week’s meeting. > > > Roberto > > _________________________________________________________________________________________________________________________ > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > exploites ou copies sans autorisation. Si vous avez recu ce message par > erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les > pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. This message and its attachments may contain confidential > or privileged information that may be protected by law; they should not be > distributed, used or copied without authorisation. If you have received this > email in error, please notify the sender and delete this message and its > attachments. As emails may be altered, Orange is not liable for messages that > have been modified, changed or falsified. Thank you. > > > > _________________________________________________________________________________________________________________________Ce > message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent doncpas etre diffuses, > exploites ou copies sans autorisation. Si vous avez recu ce message par > erreur, veuillez le signalera l'expediteur et le detruire ainsi que les > pieces jointes. Les messages electroniques etant susceptibles > d'alteration,Orange decline toute responsabilite si ce message a ete altere, > deforme ou falsifie. Merci.This message and its attachments may contain > confidential or privileged information that may be protected by law;they > should not be distributed, used or copied without authorisation.If you have > received this email in error, please notify the sender and delete this > message and its attachments.As emails may be altered, Orange is not liable > for messages that have been modified, changed or falsified.Thank you. > > > _______________________________________________ > ONAP-TSC mailing list > ONAP-TSC@lists.onap.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Dtsc&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=3WBYkehchaQg0p_gO26aU_ahomnFHCk_-us7kcQebm4&m=KpRTHgbWDYA7y1Qw30z7Rb9atvoELo18V3FhLus-ldA&s=DcotErXuv1RNud10VLMDHpHv1gpc0CCccR_epERLzkk&e= > _______________________________________________ ONAP-TSC mailing list ONAP-TSC@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-tsc
