Skip to content

allow customizing success criteria for HTTP service checks #26921

@tgross

Description

@tgross

In Nomad service discovery checks, we consider HTTP health checks successful if they return 200OK or any other status code below 400. We also ignore anything in the body. In #26900 (comment) is was suggested that it might be useful for operators to accept a different set of codes as success, and that seems safe to allow job authors to do. This would only impact Nomad service discovery; Consul would have to be implemented independently by Consul and then we could add those configuration values to the jobspec.

It was also suggested that Nomad could read the HTTP response body (because there are terrible APIs that do thing like return 200 OK with a JSON body {"message": "everything is on fire, thanks"}). This feels much more risky as now we're making the Nomad client parse arbitrary response bodies. So we probably wouldn't want to try this kind of thing.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions