efe1fa89fe
Yes, this is a huge commit.
The middleware allows you to customize the API groups of all of the
*.pinniped.dev API groups.
Some notes about other small things in this commit:
- We removed the internal/client package in favor of pkg/conciergeclient. The
two packages do basically the same thing. I don't think we use the former
anymore.
- We re-enabled cluster-scoped owner assertions in the integration tests.
This code was added in internal/ownerref. See a0546942 for when this
assertion was removed.
- Note: the middlware code is in charge of restoring the GV of a request object,
so we should never need to write mutations that do that.
- We updated the supervisor secret generation to no longer manually set an owner
reference to the deployment since the middleware code now does this. I think we
still need some way to make an initial event for the secret generator
controller, which involves knowing the namespace and the name of the generated
secret, so I still wired the deployment through. We could use a namespace/name
tuple here, but I was lazy.
Signed-off-by: Andrew Keesler <akeesler@vmware.com>
Co-authored-by: Ryan Richard <richardry@vmware.com>
82 lines
3.8 KiB
Go
82 lines
3.8 KiB
Go
// Copyright 2020 the Pinniped contributors. All Rights Reserved.
|
|
// SPDX-License-Identifier: Apache-2.0
|
|
|
|
// Package plog implements a thin layer over klog to help enforce pinniped's logging convention.
|
|
// Logs are always structured as a constant message with key and value pairs of related metadata.
|
|
//
|
|
// The logging levels in order of increasing verbosity are:
|
|
// error, warning, info, debug, trace and all.
|
|
//
|
|
// error and warning logs are always emitted (there is no way for the end user to disable them),
|
|
// and thus should be used sparingly. Ideally, logs at these levels should be actionable.
|
|
//
|
|
// info should be reserved for "nice to know" information. It should be possible to run a production
|
|
// pinniped server at the info log level with no performance degradation due to high log volume.
|
|
// debug should be used for information targeted at developers and to aid in support cases. Care must
|
|
// be taken at this level to not leak any secrets into the log stream. That is, even though debug may
|
|
// cause performance issues in production, it must not cause security issues in production.
|
|
//
|
|
// trace should be used to log information related to timing (i.e. the time it took a controller to sync).
|
|
// Just like debug, trace should not leak secrets into the log stream. trace will likely leak information
|
|
// about the current state of the process, but that, along with performance degradation, is expected.
|
|
//
|
|
// all is reserved for the most verbose and security sensitive information. At this level, full request
|
|
// metadata such as headers and parameters along with the body may be logged. This level is completely
|
|
// unfit for production use both from a performance and security standpoint. Using it is generally an
|
|
// act of desperation to determine why the system is broken.
|
|
package plog
|
|
|
|
import "k8s.io/klog/v2"
|
|
|
|
const errorKey = "error"
|
|
|
|
// Use Error to log an unexpected system error.
|
|
func Error(msg string, err error, keysAndValues ...interface{}) {
|
|
klog.ErrorS(err, msg, keysAndValues...)
|
|
}
|
|
|
|
func Warning(msg string, keysAndValues ...interface{}) {
|
|
// klog's structured logging has no concept of a warning (i.e. no WarningS function)
|
|
// Thus we use info at log level zero as a proxy
|
|
// klog's info logs have an I prefix and its warning logs have a W prefix
|
|
// Since we lose the W prefix by using InfoS, just add a key to make these easier to find
|
|
keysAndValues = append([]interface{}{"warning", "true"}, keysAndValues...)
|
|
klog.V(klogLevelWarning).InfoS(msg, keysAndValues...)
|
|
}
|
|
|
|
// Use WarningErr to issue a Warning message with an error object as part of the message.
|
|
func WarningErr(msg string, err error, keysAndValues ...interface{}) {
|
|
Warning(msg, append([]interface{}{errorKey, err}, keysAndValues...)...)
|
|
}
|
|
|
|
func Info(msg string, keysAndValues ...interface{}) {
|
|
klog.V(klogLevelInfo).InfoS(msg, keysAndValues...)
|
|
}
|
|
|
|
// Use InfoErr to log an expected error, e.g. validation failure of an http parameter.
|
|
func InfoErr(msg string, err error, keysAndValues ...interface{}) {
|
|
Info(msg, append([]interface{}{errorKey, err}, keysAndValues...)...)
|
|
}
|
|
|
|
func Debug(msg string, keysAndValues ...interface{}) {
|
|
klog.V(klogLevelDebug).InfoS(msg, keysAndValues...)
|
|
}
|
|
|
|
// Use DebugErr to issue a Debug message with an error object as part of the message.
|
|
func DebugErr(msg string, err error, keysAndValues ...interface{}) {
|
|
Debug(msg, append([]interface{}{errorKey, err}, keysAndValues...)...)
|
|
}
|
|
|
|
func Trace(msg string, keysAndValues ...interface{}) {
|
|
klog.V(klogLevelTrace).InfoS(msg, keysAndValues...)
|
|
}
|
|
|
|
// Use TraceErr to issue a Trace message with an error object as part of the message.
|
|
func TraceErr(msg string, err error, keysAndValues ...interface{}) {
|
|
Trace(msg, append([]interface{}{errorKey, err}, keysAndValues...)...)
|
|
}
|
|
|
|
func All(msg string, keysAndValues ...interface{}) {
|
|
klog.V(klogLevelAll).InfoS(msg, keysAndValues...)
|
|
}
|