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 发件人: [email protected] [mailto:[email protected]] 代表 JI, LUSHENG (LUSHENG) 发送时间: 2017年7月27日 11:44 收件人: [email protected]; NGUEKO, GERVAIS-MARTIAL; SHACHAM, RON (RON); FORSYTH, JAMES; KOYA, RAMPRASAD 抄送: [email protected] 主题: Re: [onap-discuss] [holmes][clamp][dcae][aai]Holmes Gaps to Get Over Please see in-line Lusheng From: "[email protected]" <[email protected]> Date: Wednesday, July 26, 2017 at 10:45 PM To: "JI, LUSHENG (LUSHENG)" <[email protected]>, "NGUEKO, GERVAIS-MARTIAL" <[email protected]>, RON SHACHAM <[email protected]>, "FORSYTH, JAMES" <[email protected]>, "KOYA, RAMPRASAD" <[email protected]> Cc: "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]> 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 [email protected] https://lists.onap.org/mailman/listinfo/onap-discuss
