Calculate and return best status for logical services, nodes, etc

[sethvargo]

Since this has come up a few times in different projects, I'm going to raise an issue for discussion. When determining a node's, service's, or logical service's status, one must do something like:

func statusFromChecks(checks []*api.HealthCheck) (string, error) {
    var passing, warning, unknown, critical bool
    for _, check := range checks {
        switch check.Status {
        case "passing":
            passing = true
        case "warning":
            warning = true
        case "unknown":
            unknown = true
        case "critical":
            critical = true
        default:
            return "", fmt.Errorf("unknown status: %q", check.Status)
        }
    }

    switch {
    case critical:
        return "critical", nil
    case unknown:
        return "unknown", nil
    case warning:
        return "warning", nil
    case passing:
        return "passing", nil
    default:
        // No checks?
        return "passing", nil
    }
}

TL;DR - iterate over each check and & them together to get the "best" status for the node/service/logical service.

I would like to propose that Consul does this calculation itself and exposes that result via the API and struct fields. It would be great if Consul could aggregate those checks into a single status. This would reduce a lot of duplication in our tooling and I think it would provide a better experience.

Thoughts @armon @ryanuber?

[ryanuber]

@sethvargo this seems reasonable to me - perhaps an additional field in the health responses with an aggregate status would do the trick so existing clients continue to work normally. Nice example 👍

[armon]

This could simplify some internal complexity as well, since I think there is at least 2 distinct places we calculate this.

[sethvargo]

Ping @slackpad

[slackpad]

We need to do this! Similar for the address of a service - we need to fill in the final address and not make the user look for a service address, otherwise use the node's address.

[sethvargo]

Could we dump this in a milestone for scheduling @slackpad. Seems high-value with little effort 😄

[beardedeagle]

Bump. Currently I have implemented this myself in my service check script. This would be great to have natively though.

[sethvargo]

Apparently I did this: 4179aac