Logs collector stores logs where sbctl can't find them

[xavpaice]

Bug Description

When the logs collector is run to collect logs, it stores logs in /[name]/[pod-name]/[container-name].log, if it is named, or at the root of the support bundle if it is not. If a pod contains only one container, the file is named [pod-name].log.

The clusterResources collector collects logs from containers for pods that have terminated with an error or are crash-looping, and stores them in /cluster-resources/pods/logs/[namespace]/[pod]/[container].log.

sbctl uses the clusterResources path to search for logs, which is not where the pod logs are stored for the logs collector, and so returns an error when used to read logs.

Expected Behavior

The pod logs collector stores the pod logs in the same place as the clusterResources collector, so that sbctl can find them.

Steps To Reproduce

Deploy an application into a k8s cluster, use the logs collector to collect logs from that application, then attempt to read them using sbctl to emulate the Kubernetes API using kubctl logs $pod -c $container. An error is returned, but the logs are in the support bundle.

Additional Context

Include the following information.

• Troubleshoot version: 0.42
• Operating system: OSX, linux
• Operating system version: varies
• Other details that might be helpful in diagnosing the problem

Note that this is a change to behavior - the location of logs is changed, therefore this may have an impact on existing analyzers and redactors if they are expecting log files in a particular location. This is marked as a feature as a result.

[xavpaice]

This is failing tests on preflights where it runs a run collector and collects the result, which I suppose moved as a result of the change. I've not dug into why, but that is interesting at least, and points us to need to discuss clearly if we want to solve this problem by moving pod logs to a predictable location or if we just accept that sbctl won't be able to find them. Or can we use symlinks to maintain some compatibility?

[divolgin]

I'm in favor of placing logs in a predictable location, whether they are collected with ClusterResources collector with Logs collectors.

[xavpaice]

We could consider adding a symlink such that the collector stores the actual file in the cluster-resources location, but symlinks that to the 'old' location for backwards compatibility. That way analyzers and redactors can be revised, and eventually specs migrated to use the logs collector built into clusterResources via #745 when that is implemented.

[chris-sanders]

I like using a symlink it lets us provide a deprecation period and not impact anyone now, but get the benefits immediately.

[edgarlanting]

Started to work on this change/implementation.

• Steps are:
  1. Define new path for SBCTL usage
  2. SymLink the new path to the old path for compatibility with both Troubleshoot & SBCTL

Prior to implementing the actual SymLink and testing the already available 'new' functionality, SBCTL actually misses its json files in the new cluster-resources folder.