Skip to content
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

Prioritize failed pod as debug log source for split-result RS #138

Open
KnVerey opened this issue Jul 19, 2017 · 0 comments
Open

Prioritize failed pod as debug log source for split-result RS #138

KnVerey opened this issue Jul 19, 2017 · 0 comments
Labels
✨ enhancement Improvement or small feature

Comments

@KnVerey
Copy link
Contributor

KnVerey commented Jul 19, 2017

We're currently using kubectl's built-in logic for selecting which pod to dump logs from for deployments/replicaSets. That code is here and tl;dr is trying to select a pod that is more likely to actually have logs. When all the pods in an RS are failing, this is perfect. However, when some are succeeding, this logic is likely to select the good ones, which often have a large volume of irrelevant content. We should consider something like:

if @pods.map(&:deploy_succeeded?).uniq.length > 1 # split-result ReplicaSet
  most_useful_pod = @pods.find(&:deploy_failed?) || @pods.find(&:deploy_timed_out?)
  most_useful_pod.fetch_logs
else
  # current logic
end

It's worth noting that in most cases I've seen, the bad pods in a split-result ReplicaSet are failing at a very early stage (can't pull image, can't mount volume, etc.), so in practice the effect might be suppressing irrelevant logs rather than actually grabbing relevant ones.

cc @kirs @karanthukral

@KnVerey KnVerey added the ✨ enhancement Improvement or small feature label Jul 19, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
✨ enhancement Improvement or small feature
Projects
None yet
Development

No branches or pull requests

1 participant