`BeTrue` without explanation in `Should` just prints "false is not true", which
isn't a useful failure message. Even with an explanation that message is still
printed, which is just noise. The new BeTrue/FalseBecause avoid that by
requiring that an explanation is provided and using that instead of "false is
not true".
In Kubernetes, we can enforce the usage of those better alternatives or the
if+Fail combination via forbidigo. Because we have existing code which still
needs to be updated, this can only be a hint for now.
Some examples found with this:
ERROR: test/e2e/apimachinery/protocol.go:75:20: use of `o.BeTrue` forbidden because "it does not produce a good failure message, use BeTrueBecause with an explicit printf-style failure message instead or plain Go: if ... { ginkgo.Fail(...) }" (forbidigo)
ERROR: o.Expect(ok).To(o.BeTrue())
ERROR: ^
ERROR: test/e2e_node/unknown_pods_test.go:163:52: use of `gomega.BeTrue` forbidden because "it does not produce a good failure message, use BeTrueBecause with an explicit printf-style failure message instead or plain Go: if ... { ginkgo.Fail(...) }" (forbidigo)
ERROR: }, f.Timeouts.PodStart, f.Timeouts.Poll).Should(gomega.BeTrue())
ERROR: ^
The solution might also be to write a custom matcher, but that is a bit hard to
explain in the forbidigo message.
Bumping tools to include the fix for a nil pointer
deref error in go/types. See golang/go#64812
for more details.
This fix is needed for when we bump to go1.22.
Signed-off-by: Madhav Jivrajani <madhav.jiv@gmail.com>
When dealing with unschedulable pods, the intent was to deallocate only claims
which are allocated and use delayed allocation. That if check wasn't handled
correctly, causing also claims with immediate allocation to be considered as
candidates.
Found during code reading, probably has never occurred in practice yet.
The function TryRunCommand() uses an exponential backoff,
which is good, but it's inconsistent and only used in a couple
of places.
Remove its usage in the token.go#UpdateOrCreateTokens()
and switch to using the standard function used in other places -
PollUntilContextTimeout().
Remove wait.go#TryRunCommand(), as there are no other usages.
The function wait.go#WaitForKubeletAndFunc() has been used in
a number of places in kubeadm. It starts a go routine to wait for
the kubelet /healthz and in parallel starts another go routine
to wait for an custom function.
This logic is problematic. If kubeadm is waiting for the kubelet
in parallel with something that requires the kubelet, the right
solution would be to first wait for the kubelet in serial and only
then proceed with the other action. The parallelism here particularly
during "init" required a unwanted "initial timeout" of 40s, before
the kubelet waiting even starts. In most cases, this makes the kubelet
waiter to not even start, while the main point of waiting becomes
the "other action".
- Remove the function WaitForKubeletAndFunc() from the Waiter interface.
- Rename the function WaitForHealthyKubelet() to just WaitForKubelet()
to be consistent with the naming WaitForAPI().
- Update WaitForKubelet() to not use TryRunCommand() and instead
use PollUntilContextTimeout().
- Remove the "initial timeout" of 40s in WaitForKubelet().
- Make both WaitForKubelet() and WaitForAPI() use similar error
handling and output.
- Update all usage of WaitForKubelet() to be a serial call before
any other action, such as another wait* call.
- Make the default wait timeout for the kubelet
/healthz to be 1 minute (kubeadmconstants.DefaultKubeletTimeout).
- Apply updates to all implementations of the Waiter interface.
ServicePortMap.Update() and EndpointsMap.Update() were just a tiny
wrappers around the corresponding apply() methods, which had no other
callers. So squash them together.
(Also fix the variable naming in ServicePortMap.Update() to match
other methods.)
safeIpset was a wrapper for thread-safely sharing an ipset.IPSet, but
this was unnecessary because ipset.IPSet is just a wrapper around exec
anyway and doesn't need any locking.
When users of `applyconfiguration-gen` use any of the `metav1` types in
their own types, they expect to have correct apply configurations
generated without having to explicitly pass anything to the tool. In the
same way that we used to include `metav1.ObjectMeta` and
`metav1.TypeMeta`, we now include all of the `metav1` types that have
apply-configurations generated for them in `client-go`. There's no
downside to loading these types, so there's no reason to omit any.
Signed-off-by: Steve Kuznetsov <skuznets@redhat.com>
