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

DEVOPS-7803 restore log stream #2903

Closed

Conversation

DCkQ6
Copy link

@DCkQ6 DCkQ6 commented May 24, 2024

Change Overview

Unfortunately, there is a hardcoded timeout in the kubelet server. If we want to support long-lasting phases, we need to work around it.

This PR introduces re-establishing the log stream connection while the pod is still running.

Pull request type

Please check the type of change your PR introduces:

  • 🚧 Work in Progress
  • 🌈 Refactoring (no functional changes, no api changes)
  • 🐹 Trivial/Minor
  • 🐛 Bugfix
  • 🌻 Feature
  • 🗺️ Documentation
  • 🤖 Test

Issues

Test Plan

I created a phase executing function KubeTask, with a long-lasting command (sleep). I ensured that the logs were read until the end of its execution and that the output was properly gathered.

  • 💪 Manual
  • ⚡ Unit test
  • 💚 E2E

Re-establish connection while the pod is still running
plo := &corev1.PodLogOptions{
Follow: true,
Container: containerName,
}
if sinceNow {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should it be sinceNow? Maybe we can somehow figure out the time when previous log ended?
I'm thinking if we can lose some logs this way. Probably having duplicate logs and deduplicating on log parsing is better than potentially losing some. WDYT?

Copy link
Contributor

@e-sumin e-sumin Jun 10, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Even though this solution will work in some (maybe even in most of the cases), it would be better to have something more robust.

The io.Reader returned by StreamPodLogs could be wrapped, and the last X chunks of data read, could be stored in buffer, with timestamp when it was read.
Then, when reader will be closed with EOF, streaming could be restarted since last seen data (maybe even 10 seconds before). Then everything up to seen data (including it) needs to be skipped.
In such case we will have confidence that we won't skip any output line.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for closing, I had a misunderstanding in my organization. I opened a new PR for follow-up action.

In the new PR, I have already taken this comment into account. We store the time of the last successful read, and after EOF, we request logs from that time. During tests, it shows that kubelet will always return logs starting with the last read line (even after a few hours). This always leads to duplication, never a loss of information.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@hairyhum hairyhum requested a review from e-sumin June 6, 2024 16:40
@PiwikPRO PiwikPRO closed this by deleting the head repository Jun 19, 2024
@hairyhum hairyhum mentioned this pull request Jul 25, 2024
10 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[BUG] Problem with long running phase
5 participants