Hi, We are using our custom Kubernetes cluster to deploy. Our kube enforces certain rules and that includes livenessProbe, readinessProbe to be included. It also needs resources to be defined, I am having issues with couple of things

{
	"msg": "Deployment/RELEASE-NAME-dagster-daemon: No probe defined in dagster container. Must define either a readinessProbe or livenessProbe"
},
{
	"msg": "Pod/RELEASE-NAME-dagit-test-connection: No probe defined in wget container. Must define either a readinessProbe or livenessProbe"
},
{
	"msg": "Pod/RELEASE-NAME-dagit-test-connection: CPU requests is not defined"
},
{
	"msg": "Pod/RELEASE-NAME-dagit-test-connection: Memory requests is not defined"
},
{
	"msg": "Pod/RELEASE-NAME-dagit-test-connection: CPU limits is not defined"
},
{
	"msg": "Pod/RELEASE-NAME-dagit-test-connection: Memory limits is not defined"
},
{
	"msg": "Pod/RELEASE-NAME-dagit-test-connection: Does not have a serviceAccountName defined"
}

So why is the dagit-test-connection needed, can I turn it off ? What command would serve as a readiness/livenessProbe for dagster-daemon

Hi Binoy - dagit-test-connection isn't needed for the helm chart to operate, but I don't think we currently have a flag that removes it. Is that something you can remove on your side for now while we look into this, e.g. with a tool like kustomize?

Unfortunately, it is all via helm with us.. that’s why I am packaging it within my empty helm chart via Helm dependencies. @daniel

its possible we can just remove dagit-test-connection from the chart

Oh, that would be great, if you can share the liveness probe, If you can recall, what problems were you facing with livenessProbe ?

no need to tag me i get notifications when you comment 🙂 I remember one problem was that the probe that we used reached out to the dagster DB to decide if the daemon was running, which meant that transient DB issues could also shut down the daemon. The daemon kind of implements its own liveness probe internally, in that it will shut itself down if it starts hanging. Is giving it a simple liveness probe that always returns True an option, or would that break your organization's policies?

sorry about that tagging (force of habit), and thank you for the link, and yes, i’ll take look at the livenessProbe and if that there’s internal

livenessProbe

already in dagster daemon, then I’ll probably just do a command with

ls

to return success and satisfy the rules

i think we can remove it for you

Oh wonderful, yes I can wait, I am still working on building my

values.yaml

file for deployment

yes, that's going out in the release today

cool, ty