Enable request log flag support#8958
Conversation
|
Hi @skonto. Thanks for your PR. I'm waiting for a knative member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions 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/test-infra repository. |
| Value: observabilityConfig.RequestLogTemplate, | ||
| }, { | ||
| Name: "SERVING_ENABLE_REQUEST_LOG", | ||
| Value: strconv.FormatBool(observabilityConfig.EnableRequestLog), |
There was a problem hiding this comment.
this seems worth adding a quick test for
| @@ -29,11 +30,20 @@ import ( | |||
|
|
|||
| func updateRequestLogFromConfigMap(logger *zap.SugaredLogger, h *pkghttp.RequestLogHandler) func(configMap *corev1.ConfigMap) { | |||
There was a problem hiding this comment.
this seems like it'll need updates to request_log_test.go
There was a problem hiding this comment.
Actually it was queue_test.go, for 0.17 we want things to work as previously so unit tests shouldnt break.
There was a problem hiding this comment.
queue_test.go failed because of the changes to queue.go. This requires changes to request_log_test.go because it changes the behaviour so should probably at least result in a new row in the table test or something :-).
There was a problem hiding this comment.
Yes I was referring to the failures.
There was a problem hiding this comment.
ah right, gotcha. I was just meaning "we probably need to add a test for the new logic here"
| var newTemplate string // default is an empty template, disables logging | ||
| obsconfig, err := metrics.NewObservabilityConfigFromConfigMap(configMap) | ||
| if err != nil { | ||
| logger.Errorw("Failed to get observability configmap.", zap.Error(err), "configmap", configMap) |
There was a problem hiding this comment.
probably better to do this as a guard clause at the top with a return, then the rest of the method can be out-dented
cmd/activator/request_log.go
Outdated
| logger.Errorw("Failed to get observability configmap.", zap.Error(err), "configmap", configMap) | ||
| } else { | ||
| logger.Infow("Updated the request log template.", "template", newTemplate) | ||
| if obsconfig.EnableRequestLog { |
There was a problem hiding this comment.
If EnableRequestLog is false, newTemplate will always be empty. I think this is the logic we will roll out in 0.18, but not 0.17. Is my understanding correct?
There was a problem hiding this comment.
@yanweiguo right now the logic in observability config sets everything as expected for 0.17 and 0.18. However, we need this check here so we dont pass a template that is kept in the cm while the only thing that the user changed was the flag value to false. In the latter case we have a template that is not empty but flag is false now with the new cm update, if we dont check here we will accidentally enable logging.
In the general case the observability config will set the enableRequestLog flag to true when it is needed (for 0.17, 0.18) so that is the source of truth for enabling/disabling logging at the client side.
| if err != nil { | ||
| logger.Errorw("Failed to get observability configmap.", zap.Error(err), "configmap", configMap) | ||
| return | ||
| } |
There was a problem hiding this comment.
total nit, but nicer to have a newline after a guard clause I think
| } | |
| } | |
cmd/activator/request_log_test.go
Outdated
| *ptr = val | ||
| return ptr | ||
| } | ||
|
|
There was a problem hiding this comment.
Maybe there is an option impl to use.
There was a problem hiding this comment.
There is knative.dev/pkg/ptr and then ptr.Bool.
cmd/activator/request_log_test.go
Outdated
| body: "test", | ||
| template: "", | ||
| want: "", | ||
| enableRequestLog: getBoolPtr(true), |
cmd/activator/request_log_test.go
Outdated
| body: "test", | ||
| template: "", | ||
| want: "", | ||
| enableRequestLog: ptr.Bool(true), |
There was a problem hiding this comment.
could also just explicitly put the data map in the test table, i.e. add data map[string]string as a field in the table, and then you can explicitly show the keys there/not there in each test. e.g. a row might look like
{
name: "explicitly disable request logging",
url: "http://example.com/testpage",
body: "test",
data: map[string]string{
"logging.request-log-template": "disable_request_log",
"logging.enable-request-log": "false",
},
want: "",
}
avoids the ptr stuff and the if block/dereference below, and is maybe a bit clearer? I don't feel super strongly though if you prefer this way
cmd/activator/request_log.go
Outdated
| func updateRequestLogFromConfigMap(logger *zap.SugaredLogger, h *pkghttp.RequestLogHandler) func(configMap *corev1.ConfigMap) { | ||
| return func(configMap *corev1.ConfigMap) { | ||
| newTemplate := configMap.Data["logging.request-log-template"] | ||
| var newTemplate string |
There was a problem hiding this comment.
again bit of a nit sorry, but could we move this down to just above if obsconfig.EnableRequestLog? that way the defaulting of that variable is in one place (and I think it's best if a guard is the first thing if possible anyway)
|
@julz its now updated. |
cmd/activator/request_log_test.go
Outdated
| name: "empty template", | ||
| url: "http://example.com/testpage", | ||
| body: "test", | ||
| data: map[string]string{"logging.request-log-template": ""}, |
There was a problem hiding this comment.
nice, let's touch up the formatting though since the lines get pretty long otherwise (same for all the rows in the table):
| data: map[string]string{"logging.request-log-template": ""}, | |
| data: map[string]string{ | |
| "logging.request-log-template": "", | |
| }, |
There was a problem hiding this comment.
@julz go fmt does this. Will the format you suggest pass the ci checks?
There was a problem hiding this comment.
just run go fmt after adding some newlines as above and it'll do the right thing :)
There was a problem hiding this comment.
correct I have already done it for some of them. Let me update it.
|
|
||
| func pushRequestLogHandler(currentHandler http.Handler, env config) http.Handler { | ||
| if env.ServingRequestLogTemplate == "" { | ||
| if !env.ServingEnableRequestLog { |
There was a problem hiding this comment.
do we want to handle the case where ServiceEnableRequestLog is true but ServingRequestLogTemplate is ""? (e.g. maybe this would happen with default settings in 0.17 and we'd still want to avoid bothering with the request log handler, even though it'll eventually be a no-op?)
There was a problem hiding this comment.
@julz in config_overvability.go:
if raw, ok := configMap.Data["logging.enable-request-log"]; ok {
if strings.EqualFold(raw, "true") && oc.RequestLogTemplate != "" {
oc.EnableRequestLog = true
}
}
Afaik what you describe cannot happen. We only set it to true internally in 0.17 if the template is not empty.
So even if the configmap has a value of true we push down (activator, QP) a false value.
There was a problem hiding this comment.
ok cool, sounds good to me then
|
I am wondering why |
|
The following is the coverage report on the affected files.
|
|
The following jobs failed:
Automatically retrying due to test flakiness... |
|
@markusthoemmes @julz @yanweiguo I believe this is mergeable now. |
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: julz, skonto, vagababov, yanweiguo The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Fixes #8644
Proposed Changes
based on a new flag.
Release Note
/assign @vagababov