You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
In the cases where we are using KubeTask kanister function (I think should be reproducible with any function that spins up new pod), if the command that we are running there fails we dump the entire pod spec in the controller's logs which is not useful in most of cases.
Instead of dumping the entire pod spec we should just log the information (specific fields from pod.Spec) that we might need from the pod.
To Reproduce
Steps to reproduce the behavior:
Use a blueprint that has KubeTask function in it, MySQL for example. And make sure that phase fails (we can add a command that doesn't exist and the phase will fail)
Run backup action, you can follow this readme to do that.
See the controller's logs and you will see the entire pod spec dumped in the logs
Expected behavior
We should just log the specific fields from pod.Spec that we might need to debug the problem.
Screenshots
The text was updated successfully, but these errors were encountered:
Thanks for opening this issue 👍. The team will review it shortly.
If this is a bug report, make sure to include clear instructions how on to reproduce the problem with minimal reproducible examples, where possible. If this is a security report, please review our security policy as outlined in SECURITY.md.
If you haven't already, please take a moment to review our project's Code of Conduct document.
@viveksinghggits I agree that adding entire pod spec in the controller's logs is not useful in most of cases. But it might be useful in the cases where we would want to debug the state of the Pod at the point it failed. Also, I think there is no useful information in the dump string which we would want to filter out.
Describe the bug
In the cases where we are using
KubeTask
kanister function (I think should be reproducible with any function that spins up new pod), if the command that we are running there fails we dump the entire pod spec in the controller's logs which is not useful in most of cases.Instead of dumping the entire pod spec we should just log the information (specific fields from
pod.Spec
) that we might need from the pod.To Reproduce
Steps to reproduce the behavior:
Expected behavior
We should just log the specific fields from pod.Spec that we might need to debug the problem.
Screenshots
The text was updated successfully, but these errors were encountered: