You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Thank you so much for forking and maintaining this project. This is an absolute godsend for folks that want to use EKS but find that its node rolling update mechanism is too opinionated for stateful workloads or ones that take a long time to recover after pod eviction.
I've been playing around with the tool and I am making use of the BETWEEN_NODES_WAIT wait. I noticed that this wait will also be added right after the last node has been worked on and is shut down, leading to an un-necessary wait in the tail-end of the operation.
Am I maybe missing something or is this a point of improvement?
Thank you!
The text was updated successfully, but these errors were encountered:
Am I maybe missing something or is this a point of improvement?
To be perfectly honest, we haven't looked into all the details of the implementation yet. So far we basically fixed the tool for our use-case and updated the documentation accordingly. So I couldn't tell you if there is a valid reason for the wait time after updating the last node.
If you feel like it you could do some digging, we would gladly review any PR :)
Hi!
Thank you so much for forking and maintaining this project. This is an absolute godsend for folks that want to use EKS but find that its node rolling update mechanism is too opinionated for stateful workloads or ones that take a long time to recover after pod eviction.
I've been playing around with the tool and I am making use of the BETWEEN_NODES_WAIT wait. I noticed that this wait will also be added right after the last node has been worked on and is shut down, leading to an un-necessary wait in the tail-end of the operation.
Am I maybe missing something or is this a point of improvement?
Thank you!
The text was updated successfully, but these errors were encountered: