Bump dependencies to Kubernetes 1.20
This commit is contained in:
2
vendor/github.com/go-logr/logr/README.md
generated
vendored
2
vendor/github.com/go-logr/logr/README.md
generated
vendored
@@ -41,6 +41,8 @@ There are implementations for the following logging libraries:
|
||||
- **log** (the Go standard library logger):
|
||||
[stdr](https://github.com/go-logr/stdr)
|
||||
- **github.com/sirupsen/logrus**: [logrusr](https://github.com/bombsimon/logrusr)
|
||||
- **github.com/wojas/genericr**: [genericr](https://github.com/wojas/genericr) (makes it easy to implement your own backend)
|
||||
- **logfmt** (Heroku style [logging](https://www.brandur.org/logfmt)): [logfmtr](https://github.com/iand/logfmtr)
|
||||
|
||||
# FAQ
|
||||
|
||||
|
35
vendor/github.com/go-logr/logr/discard.go
generated
vendored
Normal file
35
vendor/github.com/go-logr/logr/discard.go
generated
vendored
Normal file
@@ -0,0 +1,35 @@
|
||||
package logr
|
||||
|
||||
// Discard returns a valid Logger that discards all messages logged to it.
|
||||
// It can be used whenever the caller is not interested in the logs.
|
||||
func Discard() Logger {
|
||||
return discardLogger{}
|
||||
}
|
||||
|
||||
// discardLogger is a Logger that discards all messages.
|
||||
type discardLogger struct{}
|
||||
|
||||
func (l discardLogger) Enabled() bool {
|
||||
return false
|
||||
}
|
||||
|
||||
func (l discardLogger) Info(msg string, keysAndValues ...interface{}) {
|
||||
}
|
||||
|
||||
func (l discardLogger) Error(err error, msg string, keysAndValues ...interface{}) {
|
||||
}
|
||||
|
||||
func (l discardLogger) V(level int) Logger {
|
||||
return l
|
||||
}
|
||||
|
||||
func (l discardLogger) WithValues(keysAndValues ...interface{}) Logger {
|
||||
return l
|
||||
}
|
||||
|
||||
func (l discardLogger) WithName(name string) Logger {
|
||||
return l
|
||||
}
|
||||
|
||||
// Verify that it actually implements the interface
|
||||
var _ Logger = discardLogger{}
|
70
vendor/github.com/go-logr/logr/logr.go
generated
vendored
70
vendor/github.com/go-logr/logr/logr.go
generated
vendored
@@ -40,17 +40,16 @@ limitations under the License.
|
||||
// we want to log that we've made some decision.
|
||||
//
|
||||
// With the traditional log package, we might write:
|
||||
// log.Printf(
|
||||
// "decided to set field foo to value %q for object %s/%s",
|
||||
// log.Printf("decided to set field foo to value %q for object %s/%s",
|
||||
// targetValue, object.Namespace, object.Name)
|
||||
//
|
||||
// With logr's structured logging, we'd write:
|
||||
// // elsewhere in the file, set up the logger to log with the prefix of "reconcilers",
|
||||
// // and the named value target-type=Foo, for extra context.
|
||||
// log := mainLogger.WithName("reconcilers").WithValues("target-type", "Foo")
|
||||
// // elsewhere in the file, set up the logger to log with the prefix of
|
||||
// // "reconcilers", and the named value target-type=Foo, for extra context.
|
||||
// log := mainLogger.WithName("reconcilers").WithValues("target-type", "Foo")
|
||||
//
|
||||
// // later on...
|
||||
// log.Info("setting field foo on object", "value", targetValue, "object", object)
|
||||
// // later on...
|
||||
// log.Info("setting foo on object", "value", targetValue, "object", object)
|
||||
//
|
||||
// Depending on our logging implementation, we could then make logging decisions
|
||||
// based on field values (like only logging such events for objects in a certain
|
||||
@@ -78,9 +77,9 @@ limitations under the License.
|
||||
// Each log message from a Logger has four types of context:
|
||||
// logger name, log verbosity, log message, and the named values.
|
||||
//
|
||||
// The Logger name constists of a series of name "segments" added by successive
|
||||
// The Logger name consists of a series of name "segments" added by successive
|
||||
// calls to WithName. These name segments will be joined in some way by the
|
||||
// underlying implementation. It is strongly reccomended that name segements
|
||||
// underlying implementation. It is strongly recommended that name segments
|
||||
// contain simple identifiers (letters, digits, and hyphen), and do not contain
|
||||
// characters that could muddle the log output or confuse the joining operation
|
||||
// (e.g. whitespace, commas, periods, slashes, brackets, quotes, etc).
|
||||
@@ -91,8 +90,8 @@ limitations under the License.
|
||||
// and log messages for users to filter on. It's illegal to pass a log level
|
||||
// below zero.
|
||||
//
|
||||
// The log message consists of a constant message attached to the the log line.
|
||||
// This should generally be a simple description of what's occuring, and should
|
||||
// The log message consists of a constant message attached to the log line.
|
||||
// This should generally be a simple description of what's occurring, and should
|
||||
// never be a format string.
|
||||
//
|
||||
// Variable information can then be attached using named values (key/value
|
||||
@@ -125,11 +124,25 @@ limitations under the License.
|
||||
// - `"ts"`: the timestamp for a log line.
|
||||
//
|
||||
// Implementations are encouraged to make use of these keys to represent the
|
||||
// above concepts, when neccessary (for example, in a pure-JSON output form, it
|
||||
// above concepts, when necessary (for example, in a pure-JSON output form, it
|
||||
// would be necessary to represent at least message and timestamp as ordinary
|
||||
// named values).
|
||||
//
|
||||
// Implementations may choose to give callers access to the underlying
|
||||
// logging implementation. The recommended pattern for this is:
|
||||
// // Underlier exposes access to the underlying logging implementation.
|
||||
// // Since callers only have a logr.Logger, they have to know which
|
||||
// // implementation is in use, so this interface is less of an abstraction
|
||||
// // and more of way to test type conversion.
|
||||
// type Underlier interface {
|
||||
// GetUnderlying() <underlying-type>
|
||||
// }
|
||||
package logr
|
||||
|
||||
import (
|
||||
"context"
|
||||
)
|
||||
|
||||
// TODO: consider adding back in format strings if they're really needed
|
||||
// TODO: consider other bits of zap/zapcore functionality like ObjectMarshaller (for arbitrary objects)
|
||||
// TODO: consider other bits of glog functionality like Flush, InfoDepth, OutputStats
|
||||
@@ -171,8 +184,39 @@ type Logger interface {
|
||||
|
||||
// WithName adds a new element to the logger's name.
|
||||
// Successive calls with WithName continue to append
|
||||
// suffixes to the logger's name. It's strongly reccomended
|
||||
// suffixes to the logger's name. It's strongly recommended
|
||||
// that name segments contain only letters, digits, and hyphens
|
||||
// (see the package documentation for more information).
|
||||
WithName(name string) Logger
|
||||
}
|
||||
|
||||
// InfoLogger provides compatibility with code that relies on the v0.1.0 interface
|
||||
// Deprecated: use Logger instead. This will be removed in a future release.
|
||||
type InfoLogger = Logger
|
||||
|
||||
type contextKey struct{}
|
||||
|
||||
// FromContext returns a Logger constructed from ctx or nil if no
|
||||
// logger details are found.
|
||||
func FromContext(ctx context.Context) Logger {
|
||||
if v, ok := ctx.Value(contextKey{}).(Logger); ok {
|
||||
return v
|
||||
}
|
||||
|
||||
return nil
|
||||
}
|
||||
|
||||
// FromContextOrDiscard returns a Logger constructed from ctx or a Logger
|
||||
// that discards all messages if no logger details are found.
|
||||
func FromContextOrDiscard(ctx context.Context) Logger {
|
||||
if v, ok := ctx.Value(contextKey{}).(Logger); ok {
|
||||
return v
|
||||
}
|
||||
|
||||
return discardLogger{}
|
||||
}
|
||||
|
||||
// NewContext returns a new context derived from ctx that embeds the Logger.
|
||||
func NewContext(ctx context.Context, l Logger) context.Context {
|
||||
return context.WithValue(ctx, contextKey{}, l)
|
||||
}
|
||||
|
Reference in New Issue
Block a user