feat: add use of tolerations for starter and runner #142
Conversation
|
And one more thing: I think tolerations should be added to all pods in the operator, i.e. to the initializer pod as well. |
|
Hi @yorugac ! I re-generated the manifests. From what I see in the codebase, the Initializer is of type Also, I was wondering why you did not use the |
spoukke
force-pushed
the
feat/spoukke/add-tolerations
branch
from
707710e
to
7f55435
Compare
|
Hello @yorugac ! I juste understood what you wnted regarding the initializer. Now, the runner tolerations are mapped to the intializer one. Let me know if there is anything else |
There was a problem hiding this comment.
@spoukke thank you for the update! LGTM, merging this in now.
I've tested this a bit and in case a pod cannot be scheduled controller will be stuck at initialization. It's not related to this PR, just something that is more noticeable with usage of taints 😞 So one more TODO point to the #138.
And I missed this:
Also, I was wondering why you did not use the corev1.PoTemplate for the Runner et Starter fields instead of recreating your own struct. If you do this, you will directly have all the fields form a Pods, and the operator will automatically follow the updates from the Kubernetes API.
Good question! I cannot say for certain but I suspect it was simply easier to implement it this way. Looking it up, it seems like PodTemplate didn't always have a stable behaviour in Kubernetes API? But I think given the way fields are being added, it's worth to look into it in greater detail, to understand the pros & cons. Thanks for feedback and pointer!
This PR aims to add support for Tolerations for the starter and the different runner pods.