Speed up rolling-update - longer timeout on validation, less scheduled holds #6747
Conversation
k8s-ci-robot
added
do-not-merge/work-in-progress
|
WIP because this shouldn't go into 1.12, and will need a release note. |
There was a problem hiding this comment.
👍 lgtm
i'm into this kind of shift in rolling update timing. this looks great on my side-- as long as we sufficiently communicate to users!
should we let this simmer behind a feature flag for a version? or are release notes + a friendly log enough? i'd like to think that this change would never break my workflows, but i can imagine discovering a whole new set of subtle race conditions- which we should fix anyway.
i think my vote would be to disclose in release notes, mainline the change asap, and pray that alpha/beta release catches anything funky. perhaps my reaction is remembering early days of kops :)
justinsb
changed the title
k8s-ci-robot
removed
the
do-not-merge/work-in-progress
…d holds We reduce the amount of time we wait on a purely scheduled basis during a rolling-update, and instead increase the timeout on the validation. This will be a behavioural change - particularly for `--cloudonly` mode, but that mode seems more useful when things are going wrong anyway, when people will likely set _even lower_ timeouts.
k8s-ci-robot
added
size/M
|
Removed WIP, and added release notes for 1.15 I'm using this for my development now and it seems pretty good, and I think we should target this at 1.15 to give it more time to bake. The early kops code simply didn't have any validation logic (was purely time based) and then we hadn't shaken out most of the validation bugs. I'm sure there are more, but I think we've got the big ones! |
k8s-ci-robot
added
the
lgtm
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: justinsb, mikesplain The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
We are using these timings with all of our kops 1.12 updates. They have been working great. I would vote to merge this in sooner then 1.15 |
We reduce the amount of time we wait on a purely scheduled basis
during a rolling-update, and instead increase the timeout on the
validation.
This will be a behavioural change - particularly for
--cloudonlymode, but that mode seems more useful when things are going wrong
anyway, when people will likely set even lower timeouts.