Re: [opennms-devel] Getting node lists with status out of REST

[Craig M. <cr...@st...>]

Hi,
	Well, how about something like:
/rest/availability?filter=<whatever>

That way it's not cluttering up the information returned by the Node
rest service, and minimises the number of queries.  It's a concrete set
of data that should be exposed for reading.  Actually, given that
availability can be for a number of different entities, perhaps it
should be:
/rest/availability/<entity>?filter=<something>&period=<period>
where <entity> is "node", "service", or anything else for which OpenNMS
can calculate an availability ("applications" maybe one day?)

It can return an array of "availability" records, each specifying which
entity it refers to, and the availability over the given period.
Efficiency will be down to the server-side doing sensible queries.
Filter is optional (implying "all").

How does that sound?

Craig

On 02/09/11 04:28, Duncan Mackintosh wrote:
> (Sorry for the slow reply, bank holiday weekend made me forget about it)
> 
> Proper availability on the nodes would be nice. At the moment one can deduce it per-node anyway, as outages and number-of-services are visible, but it seems a sensible metric to expose directly.
> 
> In my specific case even your proposed availability wouldn't help, because I need data for possibly a few hundred nodes on the map at once - so if it's not in the dataset returned by opennms/rest/node/?<filter> then I'd have to fetch it one node at a time, which I suspect would kill browsers for big maps.
> 
> Having a list with little information and details available per node covers many use cases, but it makes it hard to write things like this map where I need a specific set of information about a large number of nodes at once. One option might be to expand the criteria usable in /rest/node/x/<details> and have it return a list of nodes followed by the requested information? So then I could write  opennms/rest/node/?nodeparentid=null&limit=0/availability and get a list of <node><availability/></node><node>... The server-side code would get a bit messy trying to decipher the URLs though. As you say, it could be that REST just isn't fit for that type of data set anyway.
> 
> Duncan
> 
> ________________________________________
> From: Craig Miskell [cr...@st...]
> Sent: 25 August 2011 20:59
> To: OpenNMS Code Development and Bugs
> Subject: Re: [opennms-devel] Getting node lists with status out of REST
> 
> On 26/08/11 2:04 AM, Duncan Mackintosh wrote:
>> Cheers Craig, that's about what I was assuming was the case to be honest.
>> The hardest thing I've found to try and get out of REST was 'node
> availability
>> over last X days' - the db function that calculates this looks at
> sum(outages)/count(managed services),
>> the latter of which isn't something you can fetch in bulk over REST as
> it's in the form
>> rest/nodes/<node criteria>/ipinterfaces/. I *could* expose a list of
> all ip interfaces through
>> REST, though I'm not sure if that's creeping too far. Your thoughts?
> 
> Well, I see that as an attribute of a node.  BUT, given the likely
> calculation cost (not hideous, but definitely non-trivial) *and* that it
> is over a variable number of days, I'd see it as better exposed via
> another sub resource of node, e.g.:
> /nodes/{id}/availability?hours=X
> (with various options for specifying the time period.  Any one of hours,
> minutes, seconds, days, weeks, months and years should give clients
> sufficient options :))
> 
> It's only a GETtable resource, and I think it's quite justifiably a
> separate resource because "availability" is a major and well known
> metric.  Exposing it this way would be rather cool IMHO as it's getting
> beyond just the basic data model, and into exposing the deeper
> information stored/created by OpenNMS.
> 
> There is possibly a case for creating a /node/{id}/metrics/<foo>
> hierarchy (where "availability" is the first of the possible <foo>) but
> I suspect it's too early for that (we need to see what other metrics, if
> any, need to be exposed before doing that, lest we end up with a
> lonesome single metric in a tree by itself :)).
> 
> Craig
> 
> ------------------------------------------------------------------------------
> EMC VNX: the world's simplest storage, starting under $10K
> The only unified storage solution that offers unified management
> Up to 160% more powerful than alternatives and 25% more efficient.
> Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
> _______________________________________________
> Please read the OpenNMS Mailing List FAQ:
> http://www.opennms.org/index.php/Mailing_List_FAQ
> 
> opennms-devel mailing list
> 
> To *unsubscribe* or change your subscription options, see the bottom of this page:
> https://lists.sourceforge.net/lists/listinfo/opennms-devel
> Cambridge Broadband Networks Limited Registered in England and Wales under company number: 03879840 Registered office: Selwyn House, Cambridge Business Park, Cowley Road, Cambridge CB4 0WZ, UK. VAT number: GB 741 0186 64
> 
> ------------------------------------------------------------------------------
> Special Offer -- Download ArcSight Logger for FREE!
> Finally, a world-class log management solution at an even better 
> price-free! And you'll get a free "Love Thy Logs" t-shirt when you
> download Logger. Secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsisghtdev2dev
> _______________________________________________
> Please read the OpenNMS Mailing List FAQ:
> http://www.opennms.org/index.php/Mailing_List_FAQ
> 
> opennms-devel mailing list
> 
> To *unsubscribe* or change your subscription options, see the bottom of this page:
> https://lists.sourceforge.net/lists/listinfo/opennms-devel
-- 
Craig Miskell
Systems Administrator, Catalyst IT
DDI: +64 4 8020427
==
You don't change the way people think by changing what they say.
   You change the way people think with HEADLESS CHARRED BODIES
   FLYING THROUGH THE AIR. BLOOD! FLAMES! HELLFIRE AND DAMNATION!
		-- Alistair Young