Is your feature request related to a problem? Please describe.
Running Node Red with many extensions can heavily impact startup time. I'd like to be able to implement agile liveness/readiness Probes without having to pray node-red starts all flows before the implemented initialDelaySeconds runs out and the container is being killed.
Running higher initialDelaySeconds would mean loosing sensitivity on the Probes actually measuring the flows responsiveness. I therefore suggest, the K8s default mechanics should be used - I'm aware of the implications (especially) on the sidecar and will try to document this as good as possible.
Describe the solution you'd like
The startupProbe should be made available - the same as the liveness and readiness Probe are implemented already.
Describe alternatives you've considered
increasing initialDelaySeconds on Probes: This works, but (imo) works against making the service available as fast as possible after startup, while still being able to handle the long startup of Node-Red. The StartupProbe is the response of Kubernetes to this exact problem.
Search
Code of Conduct
Additional context
No response
Is your feature request related to a problem? Please describe.
Running Node Red with many extensions can heavily impact startup time. I'd like to be able to implement agile liveness/readiness Probes without having to pray node-red starts all flows before the implemented initialDelaySeconds runs out and the container is being killed.
Running higher initialDelaySeconds would mean loosing sensitivity on the Probes actually measuring the flows responsiveness. I therefore suggest, the K8s default mechanics should be used - I'm aware of the implications (especially) on the sidecar and will try to document this as good as possible.
Describe the solution you'd like
The startupProbe should be made available - the same as the liveness and readiness Probe are implemented already.
Describe alternatives you've considered
increasing initialDelaySeconds on Probes: This works, but (imo) works against making the service available as fast as possible after startup, while still being able to handle the long startup of Node-Red. The StartupProbe is the response of Kubernetes to this exact problem.
Search
Code of Conduct
Additional context
No response