feedback.py: Don't use f-strings in logger

[tisnik]

Description

feedback.py: Don't use f-strings in logger

Type of change

• Refactor
• New feature
• Bug fix
• CVE fix
• Optimization
• Documentation Update
• Configuration Update
• Bump-up dependent library
• Bump-up library or tool used for development (does not change the final image)

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 94.88%. Comparing base (32b78e7) to head (24d8399).
Report is 17 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1622      +/-   ##
==========================================
- Coverage   94.89%   94.88%   -0.01%     
==========================================
  Files          60       60              
  Lines        2685     2681       -4     
==========================================
- Hits         2548     2544       -4     
  Misses        137      137              

Files with missing lines	Coverage Δ
ols/app/endpoints/feedback.py	100.00% <100.00%> (ø)

[tisnik]

/approve

[tisnik]

/retest

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: tisnik

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [tisnik]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[asamal4]

/lgtm

[onmete]

/hold

What is wrong with fstrings?

[asamal4]

/hold

What is wrong with fstrings?

@onmete https://docs.astral.sh/ruff/rules/logging-f-string/

[onmete]

I understand that, but using fstrings is generally more convenient and readable. The performance impact of evaluating fstring when logging is set to a higher level is less than negligible.

It is recommended by the logging, but the community is split on this topic. To me, readability has a better value here.

Either way, we should be consistent in the logging. I see we have both approaches in our code (for different levels). This PR should unify it across the whole codebase and not just small part of it - this is unnecessarily atomic change, especially with our problems/waiting times on CI.

[openshift-ci]

New changes are detected. LGTM label has been removed.

[tisnik]

Either way, we should be consistent in the logging. I see we have both approaches in our code (for different levels). This PR should unify it across the whole codebase and not just small part of it - this is unnecessarily atomic change, especially with our problems/waiting times on CI.

we are fixing it everywhere as time constraints allow us

[onmete]

Isn't it like 30 minutes at most to change it everywhere?

[openshift-ci]

@tisnik: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
ci/prow/e2e-ols-cluster-4-17	24d8399	link	true	/test e2e-ols-cluster-4-17

Full PR test history. Your PR dashboard.

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-sigs/prow repository. I understand the commands that are listed here.