-
Notifications
You must be signed in to change notification settings - Fork 0
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
Expose readiness/liveness probes #24
Comments
+1 to separate liveness and readiness checks - see Flagsmith/flagsmith#5151 for an example. I would also suggest making both checks be served over HTTP to avoid spawning new processes on the pods to run the health checks. |
With task-processor being a Django app installed on top of Core API, task-processor containers are in fact capable of using Core API's readiness and liveness probes introduced in Flagsmith/flagsmith#5151. The following PRs need to be merged before we close this:
An overall summary of the changes across the two PRs:
The minor changes and improvements include the following:
One More Thing is Flagsmith/flagsmith-common#13, which modernises flagsmith-common packaging, introduces typing and integrates APIs now common to Task processor and Core API. The next step after merging it will be porting flagsmith-task-processor over to flagsmith-common, which will decrease the maintenance overhead for our public common dependencies. |
Currently we expect orchestrators to execute a resource-heavy management command for each check. This might cause resource starvation on smaller clusters. In fact, we need to expose two health checks, preferably as HTTP endpoints:
The text was updated successfully, but these errors were encountered: