[Hawkular-dev] Availability

[John Sanda]

> On Mar 20, 2015, at 9:37 AM, Heiko W.Rupp <hrupp at redhat.com> wrote:
> 
> 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.

I suppose I am a bit biased since I work on metrics, but I do think availability should be stored in metrics. I think that the mapping functionality belongs on the client/agent side just as it was in RHQ. Those mapping functions should probably stored be stored in inventory so that users can see precisely how availability is determined for a particular type of resource and so that the user can also change how availability is calculated.