Integration of a VES agent with cloud controllers is one of the options for future development. Ceilometer as an event service under OpenStack (like Monasca etc) is architecturally an option as shown at https://wiki.opnfv.org/display/ves (though so far that focuses on DCAE events as they might be useful to export for information to the controller through the existing OpenStack plugin APIs). It just requires someone to develop the agent code (probably in python) as we have done for the C agents which report on VM events and the python collectd agent<https://git.opnfv.org/barometer/tree/3rd_party/collectd-ves-plugin/ves_plugin/ves_plugin.py> (in the OPNFV Barometer project) which reports on host events. Further, monitoring the state of the cloud controller itself (e.g. OpenStack services) is a future option for VES agent development, taking ONAP further toward a comprehensive closed-loop system for VIMs as well as NFVI/apps.
However if the intent is to capture events that otherwise could (and thus should) be obtained directly from the VM or host, it’s better to get them directly rather than proxied thru OpenStack or other cloud controllers. The scale out alarm feature (as with other AODH alarms) is a good example. It’s a better approach to get this data directly from the host or VM (depending upon what is used to trigger the threshold), rather than depend upon an additional layer (the cloud controller), as the direct approach is more efficient and portable (e.g. across VIM environments – many which will not include Ceilometer). Thanks, Bryan Sullivan | AT&T From: [email protected] [mailto:[email protected]] On Behalf Of ROSE, DANIEL V Sent: Thursday, June 22, 2017 6:51 AM To: Ethan Lynn <[email protected]> Cc: [email protected] Subject: Re: [onap-discuss] Using ceilometer to scale out VF module A dcae collector takes in some input (ceilometer) and transforms it into an output dcae can understand – there is a dcae format (which I am admittedly not familiar with). That is the proper way, rather than mapping from ceilometer to ves to dcae format so I don’t think you will find an example for anything else Thanks, Daniel Rose ECOMP / ONAP com.att.ecomp 732-420-7308 From: Ethan Lynn [mailto:[email protected]] Sent: Thursday, June 22, 2017 9:45 AM To: ROSE, DANIEL V <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> Subject: Re: Using ceilometer to scale out VF module Hi Daniel, Let’s say, if I write an agent that can receive ceilometer alarms and then transform to the format that ves can recognize, is it doable? If this is doable, is there any example that I can follow? I notice that there are some fields in ves like thresholdcrossingfields that might be a good place to put ceilometer alarm datas, but I don’t find any example there. On 22 Jun 2017, at 8:29 PM, ROSE, DANIEL V <[email protected]<mailto:[email protected]>> wrote: You would need a listener added to dcae to receive these events. One may exist (check with someone in the dcae project) but we chose ves for release 1 as it allows the vnfs to send things that would: not be monitorable in the VIM (app health for example),are receivable if one does not have access to the vim (ie on rackspace) or if one does not run on openstack (ie azure). Thanks, Daniel Rose ECOMP / ONAP com.att.ecomp 732-420-7308 From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Ethan Lynn Sent: Wednesday, June 21, 2017 11:51 PM To: [email protected]<mailto:[email protected]> Subject: [onap-discuss] Using ceilometer to scale out VF module Hi, I’m wondering is there any workable solutions to integrate ceilometer’s alarm to scale out vDNS demo. I notice that for now we are using ves client to send measurementsForVfScalingFields to DCAE collector, and DCAE will trigger a policy action to scale out a new instance. But ceilometer already do the calculation and will send out an alarm when metrics exceed some level of threshold, is it possible to let ceilometer directly send an alarm to DCAE and then trigger a policy action? Best Regards, Ethan Lynn [email protected]<mailto:[email protected]> +86 010-59934270
_______________________________________________ onap-discuss mailing list [email protected] https://lists.onap.org/mailman/listinfo/onap-discuss
