cloudnativejs/cloud-health-connect

A connect middleware for the cloud-health module, providing liveness and readiness endpoints for Kubernetes

cloud-health-connect's Issues

Update liveness status

Hi, I created a livenessCheck that just check a variable:

let isMyServiceOk;
const checker = new health.LivenessCheck('MyService', new Promise((resolve, reject) => {
    if (isMyServiceOk) {
      resolve();
    } else {
      reject({ message: 'Failed!' });
    }
}));

I registered the livenessCheck and then registered the endpoint.

const healthcheck = new health.HealthChecker();
healthcheck.registerLivenessCheck(checker);
app.use('/health', health.LivenessEndpoint(healthcheck));

I expected that if I changed the value of "isMyServiceOk" the response from /health change too, but once the promise is resolved the first time, it just return always the same status.

Is there a way to update the livenessCheck each time endpoint is called?

Can't import module from typescript

I wanted to import this module to my typescript code. I tried to do it as follows:

import * as health from "@cloudnative/health-connect";

or I even tried

import health from "@cloudnative/health-connect";

But I cannot reach exported classes (e.g. HealthChecker). I am getting undefined from calling health.HealthChecker from first option or Module "@cloudnative/health-connect/index" has no default export. in case of second option.

The only solution I found is to import it like this

import { default as health } from "@cloudnative/health-connect";

but I personally don't like it and don't understand, why I have to rename default export that looks like it doesn't even has.

Do you have any solution or recommendation how to use this package in typescript? I am using typescript v 3.6.3.

StartUp Check called twice

I noticed that my StartupCheck is executed twice. I'm not sure if I'm using it wrong or is it by design. Please help me to understand.

I have a simple Express app

const express = require('express');
const path = require('path');
const health = require('@cloudnative/health-connect');

const healthCheck = new health.HealthChecker();
const app = express();

const startPromise = () =>{
  console.log('Start Promise Is called.');
  return new Promise((resolve, reject) => {
    if (true) {
      console.log('Start Up Check Promise called');
      resolve();
    } else {
      reject();
    }
  });
}

const livePromise = () =>
  new Promise((resolve, reject) => {

    if (true) {

      console.log('Liveness probe called');
      resolve();
    } else reject();
  });

const liveCheck = new health.LivenessCheck('liveCheck', livePromise);
healthCheck.registerLivenessCheck(liveCheck);

const ReadinessCheckPromise = () =>
  new Promise((resolve, reject) => {

    if (true) {
      console.log('Readiness Check  called');
      resolve();
    } else reject();
  });
const readinessCheck = new health.ReadinessCheck('ReadinessCheck', ReadinessCheckPromise);
healthCheck.registerReadinessCheck(readinessCheck);

app.use('/status/live', health.LivenessEndpoint(healthCheck));
app.use('/status/ready', health.ReadinessEndpoint(healthCheck));
app.use('/status/healthz', health.HealthEndpoint(healthCheck));

app.listen(3000, () => {

  console.log('running on port 3000');
  const startCheck = new health.StartupCheck('startCheck', startPromise);
  healthCheck.registerStartupCheck(startCheck);
});

In the logs I see

On App Start , the logs look

 MUI running on port 3000
 Start Promise Is called.
 Start Up Check Promise called

On localhost:3000/status/ready:

MUI running on port 3000
Start Promise Is called.
Start Up Check Promise called
++Start Promise Is called.
++Start Up Check Promise called
++Readiness Check  called
++Liveness probe called

++ are marked as Added New Lines
I understand Readiness will perform Liveness check too (once), but why does it perform On StartUp too?

If I do another localhost:3000/status/ready
the logs look

MUI running on port 3000
Start Promise Is called.
Start Up Check Promise called
Start Promise Is called.
Start Up Check Promise called
Readiness Check  called
Liveness probe called
++ Readiness Check  called

Only one line added, as expected.

An in-range update of @types/node is breaking the build 🚨

The devDependency @types/node was updated from 12.7.0 to 12.7.1.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

@types/node is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details

• ❌ continuous-integration/travis-ci/push: The Travis CI build could not complete due to an error (Details).

---

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

---

Your Greenkeeper Bot 🌴

koa middleware

Is there any plan to have compatiblity with koa? a new repo perhaps, or can i contribute to make the koa integration based on this repo concept :-) ?

Do not send 503 on shutdown

According to https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#when-should-you-use-liveness-or-readiness-probes it is not necessary to send 503 on shutdown.

Note that if you just want to be able to drain requests when the Pod is deleted, you do not necessarily need a readiness probe; on deletion, the Pod automatically puts itself into an unready state regardless of whether the readiness probe exists. The Pod remains in the unready state while it waits for the Containers in the Pod to stop.

See also https://freecontent.manning.com/handling-client-requests-properly-with-kubernetes/

I think it should be avoided to have more meaning full event logs of the pods. Otherwise each shutdown generates logs of failed readiness requests

Two Readiness checks

I originally posted this in cloud-health, but have moved it here.

I registered two readiness checks (one to check a valid mongodb connection, one to check a valid redis connection). If I call resolve on the second (redis), but not the first (mongo), my status is still UP. Shouldn't it be still STARTING? If i hit the /ready api, the returned checks array is emtpy.

If I swap out registerReadinessCheck for registerLIvenessCheck both the /ready and /health routes return both checks, but the states are still off.

Here is the code:

I initialize as follows:

const health = require('@cloudnative/health-connect');
    let healthcheck = new health.HealthChecker();

Create some readiness checks:

//READINESS CHECK - MONGO
const dbConnection = new Promise(function(resolve, _reject) {
  var mongoose = require('mongoose');
  var mongoDB = 'mongodb://localhost:1234/db';
  mongoose.connect(mongoDB);
  mongoose.connect(mongoDB).then(
    () => {
      console.log('mongo connected');
      //resolve();
    },
    err => {
      //error
      console.log(err);
      _reject();
    }
  );
  // Get Mongoose to use the global promise library
  mongoose.Promise = global.Promise;

  //resolve();
});
let dbCheck = new health.ReadinessCheck('mongoCheck', dbConnection);
healthcheck.registerReadinessCheck(dbCheck);

//READINESS CHECK - REDIS
const redisConnection = new Promise(function(resolve, _reject) {

  var redis = require('./api/helpers/redisClient.js');

  redis.on('ready', function() {
    resolve();
    console.log('redis');
  });

  redis.on('error', function() {
    _reject();
  });

});
let redisCheck = new health.ReadinessCheck('redisCheck', redisConnection);
healthcheck.registerReadinessCheck(redisCheck);

And later on I do the following:

app.use('/health', health.LivenessEndpoint(healthcheck));
app.use('/ready', health.ReadinessEndpoint(healthcheck));

In summary my questions are:

1. why is the status UP when the mongo check isn't calling resolve
2. why are the returned checks an empty array?
3. if i convert readinesscheck to livenesscheck, why do both health and ready routes show STARTING that contain both the mongo check and redis check?

Thanks,
Jas

Typescript | tsconfig.json | noUnusedParameters: true produces errors

Hello

When importing module with noUnusedParameters: true compiler throws errors

You can fix if adding _ before unused variable or remove them completely

Screenshot

An in-range update of @cloudnative/health is breaking the build 🚨

The dependency @cloudnative/health was updated from 2.0.0 to 2.1.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

@cloudnative/health is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Status Details

• ✅ coverage/coveralls: First build on greenkeeper/@cloudnative/health-2.1.0 at 89.655% (Details).
• ❌ continuous-integration/travis-ci/push: The Travis CI build failed (Details).

---

Commits

The new version differs by 9 commits.

• bf70188 2.1.0
• 7262397 checks: stop getLiveness and getReadiness falling back to getStartups… (#22)
• 2663902 coveralls: revert nyc version to fix coveralls (#24)
• fb0091f doc: change the coverage badge to correct url (#23)
• d229aa4 test: add function to PingCheck, update deps (#20)
• 335f304 travis: remove Node.js 6 and 11 (#14)
• eda7e6a ping check: remove redundant function (#13)
• 0f933bb chore(package): update nyc to version 14.1.0 (#10)
• 34770db chore(package): update @types/node to version 12.0.0 (#11)

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

---

Your Greenkeeper Bot 🌴

README does not match actual results and tests.

According to the README, the Combined Health Status Code for a STARTING application should be 503 UNAVAILABLE.

However, when looking through the unit tests, I noticed that there is a test
Health returns 200 OK and STARTING on startup check starting.
(you can see that here)

I would assume that this is exact opposite of the expected result?
Which one is wrong? The README or actual code?

npm install @cloudnative/health

Trying to install as per this README.md:

npm install @cloudnative/health-connect

Fails:

npm ERR! code E404
npm ERR! 404 Not Found: @cloudnative/health-connect@latest

From log:

2 info using [email protected]
3 info using [email protected]
4 verbose npm-session 17d68231a32e5b9a
5 silly install loadCurrentTree
6 silly install readLocalPackageData
7 http fetch GET 404 https://registry.npmjs.org/@cloudnative%2fhealth-connect 431ms
8 silly fetchPackageMetaData error for @cloudnative/health-connect@latest 404 Not Found: @cloudnative/health-connect@latest

LivenessCheck with chained promises

Hi! I'm having a problem with the promise for LivenessCheck. I'm not sure if I'm doing something wrong with the promises. This is my case:
My service needs to resolve two chained promises to determine its status

const promise = doSetup()
    .then(() => checkStatus())
const livenessCheck =  new LivenessCheck('My service', promise)

doSetup() and checkStatus() return a Promise. If doSetup() or checkStatus() fail I want to show the status as DOWN during the LivenessCheck.

But somehow the result is always DOWN, even if both promises are resolved. I tried to declare or handle the promises in different ways, even removing the logic from my service, and the result is always the same.

  const promise = new Promise((resolve, reject) => {
    return Promise.resolve("Always sucessful promise 1")
      .then(() => {
        return Promise.resolve("Always successful promise 2") 
      })
      .then(resolve)
      .catch(reject)
  })
const livenessCheck =  new LivenessCheck('My service', promise) // Always DOWN

Also, if I force the second promise to reject, the result is status DOWN but the reason is empty even though I setted a message at rejection.

What could be the problem?
Thank you

Write content-type header for JSON Response

Responses with JSON payloads should have header Content-Type specified to "application/json"

Coveralls is no longer reporting code coverage

nyc has been updated (#43) and now coveralls is no longer reporting code coverage