Re: [onap-tsc] Forward:Re: Comments about Holmes

2017-06-13 Thread zhao.huabing 
Hi Oliver and Yuan,


I think the below sentence in the Holmes project proposal is able to reflect 
the consensus we have reached during Beijing meeting and what we will be trying 
to achieve in the first Release.




DCAE supports Holmes to be deployed as an analytic application in the form of 
docker(s). Actual deployment options are flexible, which should be decided by 
the user/use cases, Holmes can be either deployed as a standalone alarm 
correlation application or be integrated into DCAE as an analytic application.




https://wiki.onap.org/pages/viewpage.action?pageId=5734499




Thanks,

Huabing









Original Mail



Sender:  <spat...@research.att.com>
To: yuanyue10008526
CC:  <gilb...@mail.linuxfoundation.org> <t...@lists.onap.org> 
<onap-tsc@lists.onap.org>
Date: 2017/06/13 22:48
Subject: Re: [onap-tsc] Forward:Re:  Comments about Holmes






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 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
> 抄送人：mengzhaoxing10024238wangrui10208678
> 日 期 ：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 
&g

Re: [onap-tsc] Forward:Re: Comments about Holmes

2017-06-13 Thread SPATSCHECK, OLIVER (OLIVER) 

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 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 companie

Re: [onap-tsc] Forward:Re: Comments about Holmes

2017-06-13 Thread yuan.yue 
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









南京市雨花区软件大道50号中兴通讯3号楼1/F,Building 3, ZTE Nanjing R 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

抄送人：mengzhaoxing10024238wangrui10208678

日 期 ：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 

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

GetOutlook  for iOS  

_From: roberto.k...@orange.com  
   Sent: Wednesday, June 7, 2017 11:29 AMSubject: Re: [onap-tsc] 
Comments about HolmesTo: <   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é :

Re: [onap-tsc] Forward:Re: Comments about Holmes

2017-06-12 Thread GILBERT, MAZIN E (MAZIN E) 
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




Original Mail
Sender: zhaohuabing10201488
To: fuguangrong10144542;
CC: mengzhaoxing10024238;wangrui10208678;
Date: 2017/06/12 09:05
Subject: 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




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




GetOutlook 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