Hi，Lusheng
Thanks for your helpJ I’d like to ask UI developers to attend DCAE focus meetings. Best regards, Tao 发件人: JI, LUSHENG (LUSHENG) [mailto:l...@research.att.com] 发送时间: 2017年7月28日 21:03 收件人: shentao; fu.guangr...@zte.com.cn; NGUEKO, GERVAIS-MARTIAL; SHACHAM, RON (RON); FORSYTH, JAMES; KOYA, RAMPRASAD; don...@raisecom.com; zhang...@chinamobile.com 抄送: onap-discuss@lists.onap.org 主题: Re: 答复: [onap-discuss] [holmes][clamp][dcae][aai]Holmes Gaps to Get Over Tao, Thanks for your email. The API doc will be provided on the schedule mentioned in my previous email to Guangrong. Because DCAE is a large system, it has a large set of APIs as well. Some are used for designed interactions with other ONAP components, some are for testing and dev purposes and likely be "undocumented". Documentation will also be prioritized. Those APIs needed for R1 uses will have priority. Since this is the first communication from UI, we will need to understand your use plan so we can work together to make sure DCAE APIs support the needs of UI. I would suggest we set up a focus meeting to further the discussion. Thanks, Lusheng Ji ONAP DCAE PTL -------- Original message -------- From: shentao <shen...@chinamobile.com> Date: 7/28/17 8:45 AM (GMT-05:00) To: "JI, LUSHENG (LUSHENG)" <l...@research.att.com>, fu.guangr...@zte.com.cn, "NGUEKO, GERVAIS-MARTIAL" <gn4...@intl.att.com>, "SHACHAM, RON (RON)" <rshac...@research.att.com>, "FORSYTH, JAMES" <jf2...@att.com>, "KOYA, RAMPRASAD" <rk5...@att.com>, don...@raisecom.com, zhang...@chinamobile.com Cc: onap-discuss@lists.onap.org Subject: 答复: [onap-discuss] [holmes][clamp][dcae][aai]Holmes Gaps to Get Over Hi，Lusheng Usecase UI have the same question like Guangrong about DCAE API. We are going to provide UI functions about alarms and performance. I’d like to know what kind of data we could get from DCAE so that we can design our UI pages. Could you provide a document about DCAE API details or a list of APIs which DCAE is going to provide for R1. Best regards, Tao 发件人: onap-discuss-boun...@lists.onap.org [mailto:onap-discuss-boun...@lists.onap.org] 代表 JI, LUSHENG (LUSHENG) 发送时间: 2017年7月27日 11:44 收件人: fu.guangr...@zte.com.cn; NGUEKO, GERVAIS-MARTIAL; SHACHAM, RON (RON); FORSYTH, JAMES; KOYA, RAMPRASAD 抄送: onap-discuss@lists.onap.org 主题: Re: [onap-discuss] [holmes][clamp][dcae][aai]Holmes Gaps to Get Over Please see in-line Lusheng From: "fu.guangr...@zte.com.cn" <fu.guangr...@zte.com.cn> Date: Wednesday, July 26, 2017 at 10:45 PM To: "JI, LUSHENG (LUSHENG)" <l...@research.att.com>, "NGUEKO, GERVAIS-MARTIAL" <gn4...@intl.att.com>, RON SHACHAM <rshac...@research.att.com>, "FORSYTH, JAMES" <jf2...@att.com>, "KOYA, RAMPRASAD" <rk5...@att.com> Cc: "onap-discuss@lists.onap.org" <onap-discuss@lists.onap.org>, "denglin...@chinamobile.com" <denglin...@chinamobile.com>, "liuyuan...@chinamobile.com" <liuyuan...@chinamobile.com> Subject: [holmes][clamp][dcae][aai]Holmes Gaps to Get Over 1. Documentation - API descriptions and Dev Guides have to be provided, either formal or informal, as long as they are helpful for developers. We are now expecting documentation from projects listed below: - DMaaP (Message from @Varun Gudisena: documents to be provided by August 3rd) - DCAE [lji] We have provided sample code snippets and descriptions on DCAE project wiki under “microservice on-boarding”. You have agreed on today’ s call that this info, together with the JSON example for the #2 item below, would be sufficient for you to start working. We plan to provide high level API descriptions by M2. Full API specifications by M3. - CLAMP - A&AI If you have already provided them, please kindly let me know the link. If not, please provide a time point for the provision of those formal or informal documents. 2. @Lusheng: I will send our configuration json file to you asap. As agreed, please help to give the corresponding configurations inside DCAE back to us so that we could start to work on parsing the them in Holmes. 3. @Lusheng: As for the communication between DCAE components and other ONAP components outside DCAE, I still suggestion that DCAE to be integated with MSB. No matter whose responsiblity(DCAE or OOM) it is, we'd better figure out a way for this. [lji] Yes there needs to be a better way for information sharing in control plane. DMaaP at least provides a platform for data plane communication across different components. In general, ONAP lacks such a system wide unified run-time configuration sharing method/platform. So far two candidate methods within ONAP scope that I am aware of are via OOM or via MSB, -- and they both use Consul so it makes even more sense to harmonize there. As for DCAE, because DCAE’s service discovery mechanism is inherited from OOM code base, practically it is difficult for DCAE alone to support a discovery mechanism not aligned with OOM. 4. @Lusheng: To my understanding, all A&AI APIs which are intended for external use are RESTful. So I'm still sort of confused of what you said at the virtual meeting that "A&AI will distribute the topology information to a certain topic". I think we still need to call the RESTful APIs of A&AI to get the resource information needed for alarm correlation. Actually you have provided a way to configure the address of A&AI by hard coding them into the configuration, but it is based on the prerequisite that we are aware of the url of A&AI in advance, which I think is impossible for us during the onboarding phase. [lji] To my understanding A&AI supports two ways for sharing inventory info. One is that it actively announces updates on a DMaaP topic. Two is it passively waits for other parties to make RestAPI calls to retrieve inventory. What I do not know is whether they turn both on for ONAP configuration. For your use case it does sound like the second method is more suitable. Either way we need to know the parameters, the message topic v.s. API entry point. I think whatever that deployment plan of A&AI is will drive how such parameters are shared and used. If the plan is to use well-known topic and API entry (e.g. via well-known host name), we can have those hard-coded as part of configuration. If dynamic, this becomes the ONAP level control plane info sharing problem we are discussing under #3. 5. @Ron @Martial: If we are going to support dynamic design and deployment of rules during the run time, what do you expect from Holmes? Do you have any requirements on Holmes? If there's any, please send them to me. I'll add them to our plan if time permits.
_______________________________________________ onap-discuss mailing list onap-discuss@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-discuss
