HTTP checks in service definitions are not honored

[ryanbreen]

Attempting to use the new HTTP check syntax, I first used the inline syntax as that feels more natural for my use-case:

{
  "service": {
    "name": "icejobsservice",
    "tags": ["dev"],
    "port": 8000,
    "check": {
      "http": "http://localhost:8000/livecheck",
      "interval": "10s"
    }
  }
}

This doesn't appear to work, but this does:

{
  "check": {
    "id": "jobs_service_check",
    "name": "HTTP API on port 8000",
    "http": "http://localhost:8000/livecheck",
    "service_id": "icejobsservice",
    "interval": "10s"
  }
}

Is this a bug, an error of omission, or an error on my part?

[ryanuber]

Looks like a bug in Consul. I'll take a look at this shortly. Thanks @ryanbreen !

[ryanuber]

Notes: service registers but has 0 checks.

[ryanbreen]

To provide a bit more detail, in the first case above, I see the following results in the HTTP API:

$ curl http://localhost:8500/v1/agent/services?pretty=true
{
    "icejobsservice": {
        "ID": "icejobsservice",
        "Service": "icejobsservice",
        "Tags": [
            "dev"
        ],
        "Address": "",
        "Port": 8000
    }
}

$ curl http://localhost:8500/v1/agent/checks?pretty=true
{}

[wparad]

This seems to work as well, even if the service and check are in same file.

{
    "service": {
        "name": "service_id",
        "tags": ["tag"],
        "port": 80
    },
    "check": {
        "id" : "check_id",
        "name" : "service_id http check",
        "http": "http://localhost:80",
        "interval": "10s",
        "service_id": "service_id"
    }
}

[ryanuber]

Fixed in 3c85d7e! The problem was that we weren't reusing our own check validation function for the embedded check definitions. Thanks for the reports!