-
Notifications
You must be signed in to change notification settings - Fork 94
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
We need to re-look at liveness / readiness Probs logic of our pods #2992
Comments
Registry seems not checking anything with database at all and just simply reply OK (for both liveness & readiness): magda/magda-registry-api/src/main/scala/au/csiro/data61/magda/registry/Api.scala Line 139 in f52fcc4
|
:feature: |
At a minimum we should resolve this for these ones that utilise DB, namely authorization-api, content-api, registry-api |
correspondence utilises this well for a smtp dep (instead of db dep for the above) https://github.com/magda-io/magda/blob/master/magda-correspondence-api/src/createApiRouter.ts#L56-L67 |
turns out authorization & content are OK |
Same problem in storage-api https://github.com/magda-io/magda/blob/v0.0.58-rc.3/magda-storage-api/src/createApiRouter.ts#L31-L39 |
Add #3024 as the blocker as, currently, there is a performance bottleneck that only Our UI always sends read requests to Querying DB in readiness probe may add extra burden to it when |
We need to re-look at liveness/readiness Probs logic of our pods
We have done some work around liveness/readiness Probs for zero-downtime deployment here: #1471
We need to re-look at it to make sure that, during k8s rolling update (particularly for registry API), if DB is not accessible, will liveness/readiness Probs reports this correctly.
The text was updated successfully, but these errors were encountered: