Bumping version to include changes that
better handle TLS errors. Bump nescessary
to prepare for when the version of Go is
bumped to 1.20
Signed-off-by: Madhav Jivrajani <madhav.jiv@gmail.com>
Kubernetes-commit: 8b064fa4be71b5f1b498fabb5caade3c57f5d434
Ginkgo v2.5.0 adds support for a "timeline": a full description of what happened
while a specific test ran, including failures, timeouts, and log output.
Ginkgo v2.6.0 adds ReportBeforeSuite which we need for
https://github.com/kubernetes/kubernetes/issues/114313.
Kubernetes-commit: f3ef4004317c1a12d84021be29dd5f92badc8eff
No particular benefit and no relevant changes, it's just to stay up-to-date and
to avoid having to pull that in when merging
https://github.com/kubernetes/kubernetes/pull/111023 which indirectly depends
on the newer release.
Kubernetes-commit: 9b93cc663a102b6e36f07eecc7b6e32225f39295
- Moves kms proto apis to the staging repo
- Updates generate and verify kms proto scripts to check staging repo
Signed-off-by: Anish Ramasekar <anish.ramasekar@gmail.com>
Kubernetes-commit: c3794e2377016b1c18b1dcb63dc61d686c8ebcbf
This makes ktesting more resilient against logging from leaked goroutines,
which is a problem that came up in kubelet node shutdown
tests (https://github.com/kubernetes/kubernetes/issues/110854).
Kubernetes-commit: 3581e308835c69b11b2c9437db44073129e0e2bf
This will help us to get rid of `Ginkgo` v1 dep.
Signed-off-by: Dave Chen <dave.chen@arm.com>
Kubernetes-commit: 597071af17377f5ab4de03804b0d8b41f73fe7ce
The main practical advantage is that klog.Fatal no longer dumps the backtrace
of all goroutines.
Kubernetes-commit: f05e327ca611c23469ef41310d1d59b384cedc27
Making the LoggingConfiguration part of the versioned component-base/config API
had the theoretic advantage that components could have offered different
configuration APIs with experimental features limited to alpha versions (for
example, sanitization offered only in a v1alpha1.KubeletConfiguration). Some
components could have decided to only use stable logging options.
In practice, this wasn't done. Furthermore, we don't want different components
to make different choices regarding which logging features they offer to
users. It should always be the same everywhere, for the sake of consistency.
This can be achieved with a saner Go API by dropping the distinction between
internal and external LoggingConfiguration types. Different stability levels of
indidividual fields have to be covered by documentation (done) and potentially
feature gates (not currently done).
Advantages:
- everything related to logging is under component-base/logs;
previously this was scattered across different packages and
different files under "logs" (why some code was in logs/config.go
vs. logs/options.go vs. logs/logs.go always confused me again
and again when coming back to the code):
- long-term config and command line API are clearly separated
into the "api" package underneath that
- logs/logs.go itself only deals with legacy global flags and
logging configuration
- removal of separate Go APIs like logs.BindLoggingFlags and
logs.Options
- LogRegistry becomes an implementation detail, with less code
and less exported functionality (only registration needs to
be exported, querying is internal)
Kubernetes-commit: 1aceac797d404b4ac3b3d02fe43d495d1f645aba
Madhav Jivrajani