Add logging design proposal

[xavpaice]

[xavpaice]

TODO: consider how this affects preflights

The support bundle collection is driven in pkg/supportbundle/collect.go, preflight in pkg/preflight/collect.go. Both run a loop over collector.Collect(opts.ProgressChan), however we're only going to want to actually get pod logs from the support bundle, not the preflights (maybe?).

[xavpaice]

I'm going to revisit the design proposal and split it into two:

• simple logging alterations, so that the goal here is met
• take the more complex refactor of log collection and concurrent collections to it's own, separate, proposal which likely has a different priority and different discussion/decision points.

[xavpaice]

This proposal has been updated to be more accurate to our needs now.

[banjoh]

I'm going to revisit the design proposal and split it into two:

• simple logging alterations, so that the goal here is met
• take the more complex refactor of log collection and concurrent collections to it's own, separate, proposal which likely has a different priority and different discussion/decision points.

Also the dependsOn (including run phases) feature is non-trivial and will most likely need a separate proposal.

[xavpaice]

Also the dependsOn (including run phases) feature is non-trivial and will most likely need a separate proposal.

Indeed it isn't simple, my concern is that we have identified cases where folks are relying on the ordering in yaml to provide sequencing, and are going to need some kind of replacement even though we do not guarantee the sequencing at this stage.

I note that we don't seem to promise the sequence of collectors anywhere in the docs, and the example that was mentioned involved an exec followed by copy which isn't a pattern we should support in any case - we should never write to a pod's storage when running a collector, ideally not even logs.

In which case, are we agreed that we can leave the dependsOn for a separate proposal, to be evaluated based on whether it's needed, after the collectors are run async?

We could, at this stage, split this into 3 now:

• some proposal around having a generic log collector that all others can use (obtaining the list of pods from the parent process via some means)
• a proposal to run the collectors in goroutines
• a proposal to add a dependsOn flag for collectors to depend on other collectors

[xavpaice]

Closing this, have added #809, #810 and #811 which replace this PR