- Notifications
You must be signed in to change notification settings - Fork1k
fix: provisionerd: add more context to logs emitted, fix log level#6508
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Changes fromall commits
File filter
Filter by extension
Conversations
Uh oh!
There was an error while loading.Please reload this page.
Jump to
Uh oh!
There was an error while loading.Please reload this page.
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -880,7 +880,7 @@ func (r *Runner) buildWorkspace(ctx context.Context, stage string, req *sdkproto | ||
| } | ||
| switch msgType := msg.Type.(type) { | ||
| case *sdkproto.Provision_Response_Log: | ||
| r.logProvisionerJobLog(context.Background(),msgType.Log.Level,"workspaceprovisioner job logged", | ||
| slog.F("level", msgType.Log.Level), | ||
| slog.F("output", msgType.Log.Output), | ||
| slog.F("workspace_build_id", r.job.GetWorkspaceBuild().WorkspaceBuildId), | ||
| @@ -895,8 +895,9 @@ func (r *Runner) buildWorkspace(ctx context.Context, stage string, req *sdkproto | ||
| }) | ||
| case *sdkproto.Provision_Response_Complete: | ||
| if msgType.Complete.Error != "" { | ||
| r.logger.Warn(context.Background(), "provision failed; updating state", | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others.Learn more. note: logging at level ERROR breaks existing unit tests, and I don't want to set There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others.Learn more. Understandable. It might be the "correct" approach though, if we expect errors to be logged, then setting IgnoreErrors seems like the right course of action. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others.Learn more. @mafredri Would you agree that anything "ERROR" and above should be mainly for events useful to a system administrator? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others.Learn more. Could be relevant for e.g. template authors, but generally I doubt coder/provisioner logs (via logger) would be surfaced to anyone but systems admins. | ||
| slog.F("state_length", len(msgType.Complete.State)), | ||
| slog.F("error", msgType.Complete.Error), | ||
| ) | ||
| return nil, &proto.FailedJob{ | ||
| @@ -1120,3 +1121,21 @@ func redactVariableValues(variableValues []*sdkproto.VariableValue) []*sdkproto. | ||
| } | ||
| return redacted | ||
| } | ||
| // logProvisionerJobLog logs a message from the provisioner daemon at the appropriate level. | ||
| func (r *Runner) logProvisionerJobLog(ctx context.Context, logLevel sdkproto.LogLevel, msg string, fields ...slog.Field) { | ||
| switch logLevel { | ||
| case sdkproto.LogLevel_TRACE: | ||
| r.logger.Debug(ctx, msg, fields...) // There's no trace, so we'll just use debug. | ||
| case sdkproto.LogLevel_DEBUG: | ||
| r.logger.Debug(ctx, msg, fields...) | ||
| case sdkproto.LogLevel_INFO: | ||
| r.logger.Info(ctx, msg, fields...) | ||
| case sdkproto.LogLevel_WARN: | ||
| r.logger.Warn(ctx, msg, fields...) | ||
| case sdkproto.LogLevel_ERROR: | ||
| r.logger.Error(ctx, msg, fields...) | ||
| default: // should never happen, but we should not explode either. | ||
| r.logger.Info(ctx, msg, fields...) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others.Learn more. In theory, it could be possible that a customer misconfigures the Coder deployment, INFO will be selected as default logging level, and it can blow up the cluster if there are thousands of logs, but that's just theory. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others.Learn more. INFO is the status quo, and the only way for someone to select a different level is to set | ||
| } | ||
| } | ||