The test for checking container restarts in a Pod with restartable-init-1
and regular-1 is flaky. Right now, when we check if restartable-init-1 has
restarted, we see if it hasn’t written the "Started" log after regular-1 has
written its "Started" log.
But even though the startup sequence starts with restartable-init-1 and then
regular-1, there’s no guarantee they’ll finish starting up in that order.
Sometimes regular-1 finishes first and writes its "Started" log before restartable-init-1.
1. restartable-init-1 Starting
2. regular-1 Starting
3. regular-1 Started
4. restartable-init-1 Started
In this test, the startup order doesn’t really matter; all we need to check is
if restartable-init-1 restarted. So I changed the test to simply look for
more than one "Starting" log in restartable-init-1's logs.
There were other places that used the same helper function DoesntStartAfter,
so replaced those as well and deleted the helper function.
* A pod with restartable init container that exits with
a non-zero code is marked as a pod succeeded phase
* A pod with restartable init containers that exits with
a non-zero code by prestop hook is marked as a pod succeeded phase
* A pod with regular container that exceeds its termination grace period
seconds is marked as a pod failed phase
* A pod with restartable init containers that exceeds its termination
grace period seconds is marked as a pod succeeded phase
* A pod with a regular container that exceeded its termination grace
period seconds by PreStop hook is marked as a pod failed phase
* A pod with restartable init containers that exceeds its termination
grace period seconds by PreStop hook is marked as a pod succeeded phase
Signed-off-by: Tsubasa Nagasawa <toversus2357@gmail.com>
This ensures that the restartable init containers receive a termination
signal even if there are any not-started restartable init containers, by
ignoring the not-running containers.
This changes the text registration so that tags for which the framework has a
dedicated API (features, feature gates, slow, serial, etc.) those APIs are
used.
Arbitrary, custom tags are still left in place for now.
This is a workaround for the issue that the kubelet cannot differentiate
the container statuses of the previous podSandbox from the current one.
If the node is rebooted, all containers will be in the exited state and
the kubelet will try to recreate a new podSandbox. In this case, the
kubelet should not mistakenly think that the newly created podSandbox
has been initialized.
The spaces are redundant because Ginkgo will add them itself when concatenating
the different test name components. Upcoming change in the framework will
enforce that there are no such redundant spaces.
This deflakes the "Containers Lifecycle should not launch second
container before PostStart of the first container completed" test by
assigning enough time to finish the postStart hook.
