[Hawkular-dev] Availability

[Heiko W.Rupp]

On 20 Mar 2015, at 13:55, Lukas Krejci wrote:

> tl;dr - your ideas match almost exactly what we discussed on the 
> meeting ;)

Nice :-)

> completely 3rd party "reporter" or maybe such reporters would be 
> hooked on the
> bus to receive "realtime" info about events and be able to compute the 
> avail
> reactively.

Yes, which is in fact something I've started yesterday for pinger 
status.code
to metrics

>
> Also, it was agreed that even the availability states are not 
> something we can
> decide upfront. Maybe we'd provide a number of avail values with 
> undefined
> meaning that only avail "reporter" would be able define or we could 
> understand
> avail as "health" ranging from 0-100% and again let the avail reporter 
> decide
> on a value.

We may need to distinguish here between external value and internal
computed state.
For external values, I think what you say is just a different version of
the mapping function(s) I proposed.
For internal processing, I think we need to have a set of read-made
values that we map the external ones to.

In the computed resource state email I got those:

UP: Resource is available and working normally
DEGRADED: Resource is available but not at full performance
DOWN: Resource is at fault and not working normally
MISSING: The resource was recorded in inventory, but does not exist in 
reality (e.g. was deleted on file system)
ADMIN_DOWN/DISABLED: The resource exists, but was disabled by the admin 
(e.g. a network interface on a 8 port card where only 1 cable is 
connected)
UNKNOWN: Resource state can not be determined
MIXED: for groups / applications

And then, but which I now think should be orthogonal:
MAINTENANCE: There is a scheduled maintenance period, availability may 
be UP or DOWN

>
> On metrics level, the agreement was to keep the "availability" 
> endpoints to be
> able to distinguish it from "normal" metrics. But there also were 
> suggestions
> to just be able to mark some metrics as run-length encoded and 
> consider avail
> as an ordinary metric.

I am not convinced (yet) that availability should be recorded into 
Hawkular-Metrics,
as the Metrics api is lacking the mapping functionality.
I rather think we need "Hawkular-Availability" which offers some 
end-points + api
and which then defers the storage to the Hawkular-Inventory metrics 
storage engine.