-
Bug
-
Resolution: Done
-
Normal
-
4.13
-
Quality / Stability / Reliability
-
False
-
-
None
-
Moderate
-
No
-
None
-
None
-
CFE Sprint 234, CFE Sprint 235
-
2
-
None
-
None
-
None
-
None
-
None
-
None
-
None
Description of problem:
In OCP, for any CR "xxxxxx.operator cluster":
Updating logLevel field, then the operand pods will renew and their log level will change accordingly.
Updating operatorLogLevel, then the operator pod logs' verbosity will change accordingly.
Take openshift-apiserver operator for example:
For operand, update logLevel:
$ oc patch --type=merge openshiftapiserver.operator cluster -p='{"spec":{"logLevel":"Trace"}}'
openshiftapiserver.operator.openshift.io/cluster patched
Operand pods are renewed:
$ oc get po -n openshift-apiserver
NAME READY STATUS RESTARTS AGE
apiserver-7b7c6dc9c4-75xrh 2/2 Running 0 2m11s
apiserver-7b7c6dc9c4-dhj7d 2/2 Running 0 1m44s
apiserver-7b7c6dc9c4-lzwnl 2/2 Running 0 18s
Operand pod log level changes to -v=6, i.e. "Trace":
$ oc get po -n openshift-apiserver apiserver-7b7c6dc9c4-lzwnl -o yaml
...
exec openshift-apiserver start ... -v=6
...
For operator, update operatorLogLevel:
$ oc patch --type=merge openshiftapiserver.operator cluster -p='{"spec":{"operatorLogLevel":"TraceAll"}}'
openshiftapiserver.operator.openshift.io/cluster patched
$ oc get event -n openshift-apiserver-operator
38s Normal OperatorLogLevelChange namespace/openshift-apiserver-operator Operator log level changed from "Normal" to "TraceAll"
Operator pod's logs become verbose as per the Response Body's verbosity:
$ oc logs <operator pod> -n openshift-apiserver-operator
...
I0311 12:22:31.498722 1 request.go:1171] Response Body: {"kind":"Event",..."reason":"OperatorLogLevelChange","message":"Operator log level changed from \"Normal\" to \"TraceAll\"","source":{"component":"openshift-apiserver-operator-loggingsyncer"},...}
I0311 12:22:31.500004 1 request.go:1169] Response Body:
00000000 6b 38 73 00 0a 0f 0a 02 76 31 12 09 43 6f 6e 66 |k8s.....v1..Conf|
00000010 69 67 4d 61 70 12 a0 08 0a cd 01 0a 05 61 75 64 |igMap........aud|
...
However, for cert-manager operator, for CR "certmanager.operator":
$ oc get certmanager.operator cluster -o yaml
...
spec:
logLevel: Normal
managementState: Managed
observedConfig: null
operatorLogLevel: Normal
...
Updating them:
$ oc patch --type=merge certmanager.operator cluster -p='{"spec":{"logLevel":"Trace"}}'
$ oc patch --type=merge certmanager.operator cluster -p='{"spec":{"operatorLogLevel":"TraceALL"}}'
$ oc get certmanager.operator cluster -o yaml
...
spec:
logLevel: Trace
managementState: Managed
observedConfig: null
operatorLogLevel: TraceALL
...
Then check operand pods:
$ oc get po -n cert-manager
NAME READY STATUS RESTARTS AGE
cert-manager-cainjector-75fcd87cd4-lh5qf 1/1 Running 0 48m
cert-manager-d464b7449-p7ggf 1/1 Running 0 48m
cert-manager-webhook-6c7678c88f-2dz5v 1/1 Running 0 48m
They are not renewed.
Log level is not changed:
$ oc get po -n cert-manager -o yaml | grep '\--v'
- --v=2
- --v=2
- --v=2
Check operator pod, the pod's logs' verbosity is not changed.
Version-Release number of selected component (if applicable):
cert-manager operator of bundle version v1.10.2-18
How reproducible:
Always
Steps to Reproduce:
1. As above
Actual results:
logLevel and operatorLogLevel fields do not work for "certmanager.operator"
Expected results:
logLevel and operatorLogLevel fields should respectively work for operand and operator, like any other instances of "xxxxxx.operator"s in OCP as above openshiftapiserver.operator example. Otherwise these fields' presence in "oc get certmanager.operator cluster -o yaml" will confuse users. Despite users can change operand log level via https://github.com/openshift/cert-manager-operator/pull/95 .