Remove logging calls from library code

[tchap]

Some parts of the codebase contain logging calls right before returning an error to the caller.
This library code (e.g. interface implementation) should probably just return the error and let the caller do logging.

Issue created based on #330 (comment)

[kfswain]

I'm not sure if this is needed. I don't mind the logs tbh. LMKWYT tho

While the quote is rather opinionated, I do think it makes a fair point. Pulled from: https://github.com/go-logr/logr?tab=readme-ov-file#a-minimal-logging-api-for-go

Many people assert that libraries should not be logging, and as such efforts like this are pointless. Those people are welcome to convince the authors of the tens-of-thousands of libraries that DO write logs that they are all wrong. In the meantime, logr takes a more practical approach.

[tchap]

I'm not sure if this is needed. I don't mind the logs tbh. LMKWYT tho

Yeah, this is clearly not black and white. I just created the issue to evaluate this later.

What I meant are logging calls where you do

1. Log error.
2. Return the error to the caller.
3. Log the error right again.

This is just spamming logs.

But generally speaking, the context can be different for both calls, you can know different things at different places. I guess this is also a reason why logs are sometimes associated with a trace ID within the whole telemetry so that you can link multiple log entries together. This might actually be a more interesting question. Can we link multiple log entries together?

[kfswain]

Ahh yes, this SGTM for sure. I'll leave this open and we can revisit as needed.

I don't have a strong opinion for now, I think as the product matures and we go through debugging pain we will have more opinions.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[nirrozenbaum]

/remove-lifecycle rotten

keeping this open and marking as a good-first-issue

[phuhung273]

/assign