-
Notifications
You must be signed in to change notification settings - Fork 30
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
Small question. #1
Comments
hello @iwasaki-kenta and sorry for the late response. I don't think there's a risk of race condition here: the controller receives one event at a time, and processes it accordingly. In the podset-operator/pkg/controller/podset/podset_controller.go Lines 109 to 115 in b30288a
pending or running state, then they are counted, unless they already have a deletion timestamp set (in which case they will have move to terminating state which will trigger another call to the Reconcile method). (podset-operator/pkg/controller/podset/podset_controller.go Lines 122 to 129 in b30288a
Finally, if the current number of pods does not match the expectation, the controller scales up or down a single pod. Since a pod is created or terminated, the I hope this clarifies. |
I know this is a relatively old project at this point, but there is definitely a race condition here (evidenced by this demo of a slightly modified variant of the code). @xcoulon I've found a fix, but it isn't perfect. Using predicates, we can prevent the Reconcilerfrom waking up on certain events (in this case, updates). This works, but it prevents new pods from spinning up until after other pods have finished terminating.
|
podset-operator/pkg/controller/podset/podset_controller.go
Line 58 in b30288a
Just out of curiosity, wouldn't watching for all pod events (pending, running, terminating, etc.) cause a race condition in the reconciliation loop where pods might keep getting created (even when a sufficient amount of pods as requested in the spec were created)?
The way I am looking at it is if a pod gets spawned (which concurrently triggers the reconciliation loop again), then the number of running pods would not have updated in time and thus cause another pod to be erroneously spawned.
If not, what exactly is preventing such a race condition from happening?
The text was updated successfully, but these errors were encountered: