Allow specifying a status field when registering checks.

[Heuriskein]

Allow specifying a status field in the agent/service/register and agent/check/register endpoints.

This status must be one of the valid check statuses: 'passing', 'warning', 'critical', 'unknown'.
If the status field is not present or the empty string, the default of 'critical' is used.

This resolves issue #706

Feedback welcome on anything, of course, but I'm particularly interested in:

• Where should the ValidStatus function (in consul/structs/structs.go) go? What should it be named?
• Should the unknown status be acceptable when creating a new check?

[salehe]

I'm restating my opinion on #668 here :)
I think the best approach is to deprecate unknown state (less burden on client to reason about) and provide a default state when registering a service (delegate the reasoning to the registrar). This default indicates:

• state of service when there is no check registered
• state of a new check while it's status is unknown (no need to provide a default state while registering a check)

This approach prevents unnecessary race conditions and also generalizes service queries (e.g. DNS queries)

[ryanuber]

@salehe we will still need to be able to pass check status during check registration, because we have service checks as well as node checks (not attached to any particular service). We should support passing the status in for both. This also keeps things simple. We would otherwise need to create a new field for storing the default status of the service, and persist that with the registration to be able to use it as checks were added later on.

[armon]

@Heuriskein We should not allow "unknown" as it is being deprecated. It is already mostly on the way out, but the constants are left for backwards compatibility�.

[Heuriskein]

Removed unknown.

On Mon, Apr 13, 2015 at 12:47 PM, Armon Dadgar notifications@github.com
wrote:

@Heuriskein https://github.com/Heuriskein We should not allow "unknown"
as it is being deprecated. It is already mostly on the way out, but the
constants are left for backwards compatibility.

—
Reply to this email directly or view it on GitHub
#859 (comment).

[armon]

@Heuriskein Thanks! Sorry about the delay!