foundation-2016 auto-merges forward to release-18.0.3 (which in turn merges forward to develop)

Can you please also pull this this fixinto release-18.0.3 ?

Merged the PR to foundation-2016.

This end point was designed primary for Compass (the iOS/Android app for OpenNMS).

The intention of this end point is to list all the outstanding outages regardless the time where they were generated, plus the closed outages from the last week (based on the time from which the request has been sent).

I fixed the calculation of the week range, as it was wrong, and I also provided a way to specify a discrete start/end date (specified as timestamp in milliseconds) but this will affect ONLY the closed outages, as the outstanding outages will always going to be generated.

If you want to be able to filter by range no matter which kind of outage is recorded for a given node, this end-point is not good for you, and we need to implement a brand new end point for your use case. So, please create a new enhancement request for this.

It is important to keep in mind that this and all the rest of the available end points are going to work as described here:

http://docs.opennms.org/opennms/releases/18.0.2/guide-development/guide-development.html#_rest_api

The data will always going to be paginated, as building and returning an XML with 10000 records can have a serious impact on the OpenNMS server. You can eliminate the pagination but I would test it on a devel/test server first (to understand the impact for a node on which you know you have thousands of entries). If you're performing this request from a script, you can always create a loop to retrieve all the outages you need in small chunks (which is more performant). In fact, the best solution for your use case is to query the database directly, if you want to perform big queries quickly without affecting the performance of OpenNMS.

I want to use this service to recreate functionality similar to Zenoss' get_archivePingEvents function. In their API I reference the device id and, in this example, request the last 10,000 outage events. I'm interested in comparable functionality from this API call, however rather than an event count limit being able to to specify a relative or absolute start and end time period would be amazing.

Here's the call that I make in Zenoss using their rest API

events = z.get_archivePingEvents(device="CPE Router$", limit=10000)['events']

The returned data, json encoded looks like this (heavily trimmed):

{{
[
{
"component": {
"text": "",
"uid": null
},
"count": "3",
"device": {
"text": "CPE Router",
"uid": "/zport/dmd/Devices/Network/Router/Cisco/devices/192.168.1.10"
},
"eventClass": {
"text": "/Status/Ping",
"uid": "/zport/dmd/Events/Status/Ping"
},
"eventState": "New",
"evid": "4dcbc07e-57fd-449f-9548-f2f2097d840d",
"firstTime": "2016-11-08 07:45:07",
"id": "4dcbc07e-57fd-449f-9548-f2f2097d840d",
"lastTime": "2016-11-08 07:47:07",
"severity": "5",
"summary": "ip 192.168.1.10 is down"
},
{
"component": {
"text": "",
"uid": null
},
"count": "3",
"device": {
"text": "CPE Router",
"uid": "/zport/dmd/Devices/Network/Router/Cisco/devices/192.168.1.10"
},
"eventClass": {
"text": "/Status/Ping",
"uid": "/zport/dmd/Events/Status/Ping"
},
"eventState": "New",
"evid": "7c4ecfe6-49c2-4989-9d58-9b149f701fdc",
"firstTime": "2016-11-08 07:03:06",
"id": "7c4ecfe6-49c2-4989-9d58-9b149f701fdc",
"lastTime": "2016-11-08 07:05:06",
"severity": "5",
"summary": "ip 192.168.1.10 is down"
}]
}}