The revised logging emits one log entry at the start of
round-tripping ("Request") and another at the end ("Response"). This avoids the
risk that related output gets interleaved by other output.
No API changes are necessary. A contextual logger is picked up from the context
of the request that is being handled. The verbosity level of that logger is
checked to determine what is supposed to be logged. This enables reducing log
details on a by-request basis by storing a `logger.V(1)` in the context of the
request.
As before, logging only gets injected into request processing at -v6 or higher,
so normally there is no additional overhead.
This uses generics to generalise the various CreateOrUpdate,
CreateOrRetain etc. functions. Where appropriate, the context is added
as an initial argument to the new functions.
ConfigMapMutator isn't used anywhere else, so it's dropped in favour
of the private objectMutator added in this commit.
Signed-off-by: Stephen Kitt <skitt@redhat.com>
The context is used for cancellation and to support contextual logging.
In most cases, alternative *WithContext APIs get added, except for
NewIntegerResourceVersionMutationCache where code searches indicate that the
API is not used downstream.
An API break around SharedInformer couldn't be avoided because the
alternative (keeping the interface unchanged and adding a second one with
the new method) would have been worse. controller-runtime needs to be updated
because it implements that interface in a test package. Downstream consumers of
controller-runtime will work unless they use those test package.
Converting Kubernetes to use the other new alternatives will follow. In the
meantime, usage of the new alternatives cannot be enforced via logcheck
yet (see https://github.com/kubernetes/kubernetes/issues/126379 for the
process).
Passing context through and checking it for cancellation is tricky for event
handlers. A better approach is to map the context cancellation to the normal
removal of an event handler via a helper goroutine. Thanks to the new
HandleErrorWithLogr and HandleCrashWithLogr, remembering the logger is
sufficient for handling problems at runtime.
Dual-stack clusters exist; ServiceChangeTracker does not need to log
messages (even at V(4)) when it sees dual-stack Services, and
EndpointsChangeTracker does not need to emit Events(!) when it sees
EndpointSlices of the wrong AddressType.
(Though in most cases the EndpointsChangeTracker Events would not get
emitted anyway, since the MetaProxier would ensure that only the v4
tracker saw v4 slices, and only the v6 tracker saw v6 slices.)
Also remove a nil check labeled "This should never happen" which, in
fact, we know *didn't* happen, since the function has already
dereferenced the value before it checking it against nil.
newFakeProxier was inlining the details of NewEndpointsChangeTracker
so it could override trackerStartTime, but it would be better and more
future-proof to just call NewEndpointsChangeTracker normally and then
edit that one field.
(Also remove an unused FakeProxier field.)
