Hi Guangrong, I have some comments on your reply: please see <jcs>..</jcs>. Also, please look at the Holmes project page for additional comments from me.
regards, John 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. <jcs> Policy SHOULD be able to accommodate different programming paradigms. DROOLS is great for production rule systems, but many examples are not appropriate for that type of policy. I don't think we should limit policy to DROOLS. </jcs> 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. <jcs> Holmes sounds like a CEP module, which I think is needed. I disagree that Policy is aimed to a single action, and also disagree that it is limited to auto-scaling and -healing. Policy is about decision-making. My underlying concern is: Does Holmes define its own policy? Or does it reference Policies from other projects? Please clarify. </jcs> I think systems should be defined by what their functions rather than the technologies they adopt. <jcs> Agreed! </jcs> Besides, to make our systems easier to maintain, we have to hold on to the Single Responsibility Principle. <jcs> This has nothing to do with the Single Responsibility Principle. That being said, I repeat my question: is Holmes trying to define a new type of Policy? IF YES, then I'd like to know why. IF NO, then Holmes should more clearly state its focus (e.g., why is it MORE than a CEP module). </jcs> 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. <jcs> I don't see why the logic gets more complex. That's what the CEP module does. Please explain. </jcs> On Wed, Jun 7, 2017 at 8:29 AM, <roberto.k...@orange.com> wrote: > 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* > <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 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. > > > _______________________________________________ > ONAP-TSC mailing list > ONAP-TSC@lists.onap.org > https://lists.onap.org/mailman/listinfo/onap-tsc > > -- regards, John
_______________________________________________ ONAP-TSC mailing list ONAP-TSC@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-tsc
