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
added flag --since-time for Logs Collectors #287
Conversation
Great! I'd like to see it support |
@markpundsack Would you like to add the --since flag or do you want the --since-time flag to accept hours, |
@manavellamnimble Both have value.
Hmm... I think 'Z' means "zero offset" which means UTC. |
Btw, we don’t need to block merging this; |
@jgruica @GraysonNull We should consider adding this to the Kots web UI as well. |
@markpundsack Hi! I added the --since flag, so both can be shipped (and documented) together. |
Awesome, thank you! |
@salahalsaleh Can you review this? |
Co-authored-by: Salah Aldeen Al Saleh <salahalsaleh1993@gmail.com>
Co-authored-by: Salah Aldeen Al Saleh <salahalsaleh1993@gmail.com>
cmd/preflight/cli/run.go
Outdated
@@ -129,6 +129,29 @@ func runPreflights(v *viper.Viper, arg string) error { | |||
KubernetesRestConfig: restConfig, | |||
} | |||
|
|||
if v.GetString("since-time") != "" { | |||
if v.GetString("since") != "" { | |||
progressChan <- errors.Errorf("Only one of since-time / since may be used. The flag since-time will be used.") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is that how Kubectl handles it? Or does it abort because of invalid args?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes I had my doubts about this too. K8s aborts with the message error: parsing time
. I followed the error handling for the limits in the logs collector (communicating it through the progress channel), but it would make sense to abort because if someone used the flag and it can't be parsed maybe there would be no point in running through all the collectors and analyzers
Co-authored-by: Mark Pundsack <markpundsack@users.noreply.github.com>
Co-authored-by: Mark Pundsack <markpundsack@users.noreply.github.com>
Co-authored-by: Mark Pundsack <markpundsack@users.noreply.github.com>
Co-authored-by: Mark Pundsack <markpundsack@users.noreply.github.com>
@markpundsack based on what we discussed, I've redesign the solution. Before running the collectors, the flags are parsed to time variable to check if it is all right, and throws an error if there is something wrong. All of this happens in a separate function to make it more organized. This modification also requires just one extra field in log.limits (not two) and requires less work to implement in the log collector. @salahalsaleh Can you please check it? |
Thanks for the changes. BTW, do we not have tests on this project? |
@markpundsack @divolgin Hi, this is the first approach for a flag to determine a point of time, from which the logs collector should start collecting logs. It overrides all the logs collectors, and keeps the maxLine parameter from the original specs. Let me know what you think of it. Fix #277 An example:
$ kubectl support-bundle --since-time="2020-10-19T12:36:23Z" file_or_url