Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Bury KubeletConfiguration.ConfigTrialDuration for now #59628
Based on discussion in https://github.com/kubernetes/kubernetes/pull/53833/files#r166669046, this PR chooses not to expose a knob for the trial duration yet. It is unclear exactly which shape this functionality should take in the API.
For context, here is a re-print of the discussion on the kubeletconfig-to-beta PR:
liggitt 2 days ago Member
mtaufen 2 days ago Member
As third option, we could consider
As a fourth option, we could remove the external knob altogether, have the Kubelet just use 10 minutes as an internal default, and decide where to expose control of last-known-good later on (I don't really like kicking the can down the road, but it's an option).
liggitt 12 hours ago • edited Member
liggitt 12 hours ago Member
mtaufen 7 hours ago Member
referenced this pull request
Feb 9, 2018
moving internally for now LGTM
as an aside, there are normal conditions where the kubelet exits/restarts (waiting on client credential grants, or an available API server, etc). how does this interact with crashloops caused by things like that? could that trigger rolling back config because the kubelet thinks the config was responsible for the crashloop?
[APPROVALNOTIFIER] This PR is APPROVED
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 OWNERS Files:
Approvers can indicate their approval by writing
Right now, this is just a grace-period after which the last-known-good updates. We removed crash-loop detection over the summer because we weren't confident the implementation covered the full spectrum of edge cases. So right now the only thing that can cause a fallback to last-known good is a failure to load the assigned config (corrupt checkpoint, invalid configuration, etc.).