naive question, how this will solve this issue #3423 (comment) ?
what different will this make?

Hi @aojea, I didn't mean that it solves that issue.
I meant that there are cases where init logs at runtime, like the case related to that issue, are useful for debug.

sure, just trying to understand what are those cases, on my experience kind export logs is always enough, so I'm trying to understand what I'm missing

I get what you mean, I agree that the same logs are available also with export logs, and at the end you can use both ways to debug, but in this case without needing to save all available logs on disk.
I'm not saying that one way is better than another but that sometimes you don't need all the logs to be exported and just the init log at runtime can provide enough information to debug issues like the one linked.

Usually the container log isn't where the problem is, and we wind up needing the component logs. (IE export logs)

That's why I'm proposing to add the ability to make it print them (eg systemd logs) when maximum verbosity is set, besides the ability to export them all

That's why I'm proposing to add the ability to make it print them (eg systemd logs) when maximum verbosity is set, besides the ability to export them all

I don't see why this makes more sense than export logs, it will be really hard to pick through all of these being dumped from the same process and I've never seen another cluster tool do this.

I think this is just going to cause users to paste useless log snippets and ignore the instructions to use kind export logs for detailed logs when things break.

What if we automatically did ~kind export logs on kind create cluster failure, with some knobs to opt out and to control where these go?