Include clusterversion and machineconfigpool in the logging's must-gather
oarribas opened this issue · comments
Include the clusterversion and the machineconfigpool, adding the following to the must-gather script, as they have useful information about the state of the cluster if no "default" must-gather executed:
resources+=(clusterversion)
resources+=(machineconfigpool)
- resources+=(clusteroperators) - # Not this one
The cluster-logging must-gather is intended to be an extra dump you might want to take in addition to the default must-gather. That's why it is minimalistic. I disagree adding those two here as if they blow up the tarball in the end. If these two resources are minimal, please elaborate how they add value to debugging the OpenShift Logging stack.
Hi @periklis ,
clusterversiononly adds one yaml, and it's useful to check the version of the OCP cluster, and also if there is an upgrade in place or if there are any other issues with the cluster operators.clusteroperatorsincludes lots of things, so probably it's better to not include it.
Also, as nodes is already included, I think that machineconfigpool could be also interesting. It only adds one yaml per mcp, and it will show if any node is updating (even if all are Ready).
On the other hand, if it's expected to collect the logging must-gather in addition to the default must-gather, it would be better to change the command to collect both in the readme to:
oc adm must-gather --image-stream=openshift/must-gather --image=quay.io/openshift/origin-cluster-logging-operator -- /usr/bin/gather
** not sure if the -- /usr/bin/gather is required for the logging must-gather, as it's the default for the default must-gather
https://github.com/openshift/cluster-logging-operator/blob/master/must-gather/README.md#usage
@oarribas TIL that you can declare multiple must-gather images per command. This is an excellent change to contribute to the projects. Would you like to add this to the README.md in addition to the present command? I would suggest to add them both and let our users decide which one to pick.
Issues go stale after 90d of inactivity.
Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.
If this issue is safe to close now please do so with /close.
/lifecycle stale
Stale issues rot after 30d of inactivity.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen.
If this issue is safe to close now please do so with /close.
/lifecycle rotten
/remove-lifecycle stale
Rotten issues close after 30d of inactivity.
Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.
/close
@openshift-bot: Closing this issue.
In response to this:
Rotten issues close after 30d of inactivity.
Reopen the issue by commenting
/reopen.
Mark the issue as fresh by commenting/remove-lifecycle rotten.
Exclude this issue from closing again by commenting/lifecycle frozen./close
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.