Logging in rest.Request.Body cannot be made context-aware without an API
change. Such a change is complicated if done in a backwards-compatible
fashion (must change lots of callers in Kubernetes) and prohibitive if not (all
callers of Body would have to pass a context).
Instead, logging of the request body gets moved into the functions which send
the request. This is a change of behavior, but it is limited to log levels >= 8
and thus should have no impact in production.
A request which gets sent multiple times will also log the body multiple
times. This might even be a good thing because it serves as reminder what is
being sent when it is being sent.
While at it, stack backtracing gets enhanced so that the caller of the REST API
is logged and tests for the new behavior get added.
This change renames NewTypedDelayingQueue to NewTypedDelayingQueue to
stay consistent with the naming scheme in the package. A
NewTypedDelayingQueue constructor is kept for backwards compatibility
but marked as deprecated.
With embedded structs, objects can end up with conflicting members.
These aren't ambiguous in Go, but applyconfiguration-gen's generated
functions ignore this possibility and produce ambiguous member
accesses and duplicate methods.
This resolves the problem by qualifying embedded member accesses with
their types when appropriate, and by memoizing generated function
names to avoid duplicates. When conflicting members are encountered,
functions are generated for the first one; this is assumed to produce
correct results.
For applyconfiguration-gen, a more correct approach would be to only
generate With... and Get... functions for the specific members the
generator is interested in; but that would be a breaking change for
any client code relying on the other With... functions.
Signed-off-by: Stephen Kitt <skitt@redhat.com>
This commit refactors the `renew` function in the leader election package to replace
the deprecated `wait.PollImmediateUntil` with `wait.PollUntilContextTimeout`.
This change simplifies the context handling by removing the need for an additional
timeout context and its cancellation.
The previous implementation created a timeout context for each retry period,
which added unnecessary complexity. The new implementation directly passes the parent
context to the retry function, ensuring that the timeout is handled within `PollUntilContextTimeout`.
This change also ensures that the context passed to `tryAcquireOrRenew` and
`tryCoordinatedRenew` is consistent, improving the readability and maintainability of the code.
