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

Add --file flag to minikube logs. #11231

Closed
andriyDev opened this issue Apr 29, 2021 · 3 comments · Fixed by #11240
Closed

Add --file flag to minikube logs. #11231

andriyDev opened this issue Apr 29, 2021 · 3 comments · Fixed by #11240
Assignees
Labels
kind/feature Categorizes issue or PR as related to a new feature. priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release.
Milestone

Comments

@andriyDev
Copy link
Contributor

We should have a --file flag in minikube logs so that logs output is sent directly to a file for easy transfer.

Before:

$ minikube logs
<tons of output>

After:

$ minikube logs --file out

File 'out' written full of logs.

@medyagh medyagh added kind/feature Categorizes issue or PR as related to a new feature. priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release. labels Apr 29, 2021
@spowelljr
Copy link
Member

@medyagh This seems to be the exact same thing as the existing log_file flag. Just curious why we're adding another flag that seems to do the same thing

@andriyDev
Copy link
Contributor Author

andriyDev commented Apr 30, 2021

@spowelljr The trouble with using log_file is that you get logs from the current command interspersed with logs from previous runs which can make it harder to reason about. You also get timestamps on the logged messages which can make it confusing which timestamp you should be looking at.

Another possibility was just doing minikube logs > debug.log but the problem there is that some of the logs use ErrT and others use Styled which write to different output streams, so merging that can be confusing. It also may be less portable.

This is my take on it, I would like to hear @medyagh 's thoughts as well! :)

@spowelljr
Copy link
Member

@andriyDev I wasn't able to see an example of your first point about logs from previous runs. But I see your point about the the timestamps, we definitely don't want those.

@sharifelgamal sharifelgamal added this to the v1.20.0 milestone May 3, 2021
@medyagh medyagh modified the milestones: v1.20.0, v1.21.0 May 3, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature. priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants