is details a really good name? about rfc-healthcheck

[inadarei]

I had to publish the RFC since it had expired, but happy to hear suggestion for the better naming of "details".

Regarding your other feedback: it is totally fine if you want to just return a boolean for a downstream dependency and not provide more details. This is how your example outputs would look like per RFC:

Original from github status

{"status":"good","last_updated":"2018-10-08T22:39:11Z"}

RFC version of Github status

{"status" : "pass"}

(and caching/freshness negotiation is achieved using standard HTTP headers)

Original from Gitlab status

{
   "queues_check" : {
      "status" : "ok"
   },
   "redis_check" : {
      "status" : "ok"
   },
   "shared_state_check" : {
      "status" : "ok"
   },
   "db_check" : {
      "status" : "ok"
   },
   "cache_check" : {
      "status" : "ok"
   }
}

RFC version of the equivalent for Gitlab status

{
  "status": "pass",
  "details": {
    "queues_check": {"status": "pass"},
    "redis_check": {"status": "pass"},
    "shared_state_check": {"status": "pass"},
    "db_check": {"status": "pass"},
    "cache_check": {"status": "pass"}
  }
}

[inadarei]

Thank you, Martin. You make an interesting point about objection to details. In reality what the section informs about is health of downstream dependencies. A field name "downstream-dependencies" feels too long, however...

[inadarei]

As for the spec pushing metric everywhere - I will have to disagree with it. Main reason:

Metrics are optional. You can absolutely use this spec to get the level of detail that stops as "can I use or not". However, there are cases when this simple "pass" or "fail" approach isn't sufficient. Such approach, while simple and often enough, is very reactive - you will only know things are bad once things start to "fail". There are plenty of cases when you may want to start noticing thing deteriorating before "fail" so appropriate measures can be taken. The spec merely allows such operation, without mandating it or making it necessary, so in that regard I think it hits a good middle ground.

[Kyslik]

Will any of this be included in new version of RFC version (regarding details)? Should I try to find a good replacement for details?

---

Regarding metrics; I am still convinced that health-check should return boolean only instead of array of metrics; example https://status.github.com/api/status.json https://docs.gitlab.com/ee/user/admin_area/monitoring/health_check.html; I guess it depends who is going to use the service. Maybe I am mistaking it for status, and sure health-check should also show some more info.

Perhaps include an example without the use of metrics (in the RFC)? (Maybe I just do not know how to properly read RFCs, and do not discard optional things.)

---

Thank you for the time!

[inadarei]

@Kyslik check out: #24