GitHub user potiuk added a comment to the discussion: Kubernetes scheduler liveness probe fails during OOM conditions preventing automatic restart
> Would the maintainers be open to a PR implementing the HTTP health endpoint > approach? This seems like the most robust solution that follows Kubernetes > best practices while maintaining backward compatibility. Sure. You have not explained what deployment you used in general. so hard to say what exactly scope of changes you propose - note that not every component of airflow currently has an http server so you would have to change that, also the current http servers we use - we use fast_api, might not be good idea to provide such `healhz` endpoints. Generally speaking you are probably talking about embedding and exposing another http server in evry single component of airflow - specifically for `http` /healthz check. That has certain implications (mostly about performance, memory usage and security and also would require to adapt the helm chart for example. But yes - I personally can answer that this seems like a good idea, but It's just my personal opinion. With changing general approach for it and applying it to all components (and helm chart) that kind of change would likely require a devlist discussion. You can follow our community page to see how to subscribe to it and start a "[DICCUSSION]" thread and see if you can get consensus, then later if you see the consensus you can call for `[LAZY CONSENSUS]` thread - or if people will have different opinions and you will not be able to drive it to consensus, yoy would have to starta `[VOTE]` thread. Most likely you would also - that will come in the discussion - you will have to propose a short description of the impact (i.e. describe the http.server and way how you expose it including security implications). More about decision making process and voting here https://www.apache.org/foundation/voting.html GitHub link: https://github.com/apache/airflow/discussions/53662#discussioncomment-13863259 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
