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
What steps did you take and what happened:
currently, we found two problems with the logs in velero, which is output by the internal controller-runtime. it's functioning well with sigs.k8s.io/controller-runtime in versionv0.10.2, but after upgrading to v0.12.1, there would be some problematic output logs for controllers in velero logs.
the log output pointer of the source object struct and output zero value of the struct
controller name is not related to source kind and always shows controller name is downloadrequest
What did you expect to happen:
the log output the right values of the source object
controller name is related to source kind
The following information will help us better understand what's going on:
For the first problem:As 1.9.3 we've upgrade sigs.k8s.io/controller-runtime library from v0.10.2 to v0.12.1, the library changed the direct output object to fmt.Sprintf format object way, our PeriodicalEnqueueSource struct need to provide an implementation of String function or there would be messy output about it.
For the second problem: the problem is located in codes, which has a problem with wrongly using golang closure, in L321 assigning local log variable with a global variable which makes local log variable always get the latest global variable value when global variable over written many times. And that it's the problem that always show the controller name as downloadrequest for downloadrequest is the latest assigned values to the global variable.
If you are using velero v1.7.0+:
Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]
Environment:
Velero version (use velero version):
Velero features (use velero client config get features):
Kubernetes version (use kubectl version):
Kubernetes installer & version:
Cloud provider or hardware configuration:
OS (e.g. from /etc/os-release):
Vote on this issue!
This is an invitation to the Velero community to vote on issues, you can see the project's top voted issues listed here.
Use the "reaction smiley face" up to the right of this comment to vote.
👍 for "I would like to see this bug fixed as soon as possible"
👎 for "There are more important bugs to focus on right now"
The text was updated successfully, but these errors were encountered:
@qiuming-best , I have seen this issue in my projects as well with controller-runtime, 12.1 has this issue of this log being printed same "controller name is not related to source kind and always shows controller name is downloadrequest".
What steps did you take and what happened:
currently, we found two problems with the logs in velero, which is output by the internal
controller-runtime
. it's functioning well withsigs.k8s.io/controller-runtime
in versionv0.10.2
, but after upgrading tov0.12.1
, there would be some problematic output logs for controllers in velero logs.downloadrequest
What did you expect to happen:
The following information will help us better understand what's going on:
golang
closure, in L321 assigning locallog
variable with a global variable which makes locallog
variable always get the latest global variable value when global variable over written many times. And that it's the problem that always show the controller name asdownloadrequest
fordownloadrequest
is the latest assigned values to the global variable.If you are using velero v1.7.0+:
Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]
Environment:
velero version
):velero client config get features
):kubectl version
):/etc/os-release
):Vote on this issue!
This is an invitation to the Velero community to vote on issues, you can see the project's top voted issues listed here.
Use the "reaction smiley face" up to the right of this comment to vote.
The text was updated successfully, but these errors were encountered: