Fix L7 NetworkPolicy e2e test failure

[hongliangl]

Fix L7 NetworkPolicy e2e test failure

Fix #6129

In the failure tests, the following function is called to
verify whether a connection should be allowed or denied.
To verify a connection should be denied, it requires 5 seconds.

func probeClientIPFromPod(data *TestData, pod, container string, baseUrl string) (string, error) {
	url := fmt.Sprintf("%s/%s", baseUrl, "clientip")
	hostPort, _, err := data.runWgetCommandFromTestPodWithRetry(pod, data.testNamespace, container, url, 5)
	if err != nil {
		return "", err
	}
	host, _, err := net.SplitHostPort(hostPort)
	return host, err
}

Before #5843, these e2e tests utilized the function PollImmediate
from k8s.io/apimachinery/pkg/util/wait, which immediately calls an
anonymous function including the above function. Since the timeout
is 5 seconds, and the ticker time is 1 second, and the anonymous
function runs immediately, the 5-second timeout is sufficient to
verify the denied state of a connection as mentioned above. However,
after #5843, the function Eventually from github.com/stretchr/testify/assert
is used with the same parameters, which implies that the anonymous
function runs after the first ticker time, leaving 4 seconds. 4 seconds
are insufficient to verify the denied state of a connection.

To resolve the issue, RunCommandFromPod called in
data.runWgetCommandFromTestPodWithRetry is called directly in function
Eventually to verify the connection state.

[antoninbas]

LGTM, but it feels like the methodology is not great for validating denied connections. This kind of function (assert.Eventually, wait.Poll) is really meant to perform a single validation, and retry until the validation succeeds or until a timeout. In this case here, the probe function itself includes a retry mechanism, which is not ideal.

[tnqn]

but it feels like the methodology is not great for validating denied connections. This kind of function (assert.Eventually, wait.Poll) is really meant to perform a single validation, and retry until the validation succeeds or until a timeout. In this case here, the probe function itself includes a retry mechanism, which is not ideal.

Agree with @antoninbas. It's obscure to rely on the difference between the two timeouts. It also wastes time to retry 5 times when the expectation is failure. Can we call RunCommandFromPod directly in Eventually?

[hongliangl]

but it feels like the methodology is not great for validating denied connections. This kind of function (assert.Eventually, wait.Poll) is really meant to perform a single validation, and retry until the validation succeeds or until a timeout. In this case here, the probe function itself includes a retry mechanism, which is not ideal.

Agree with @antoninbas. It's obscure to rely on the difference between the two timeouts. It also wastes time to retry 5 times when the expectation is failure. Can we call RunCommandFromPod directly in Eventually?

@tnqn Done

[tnqn]

LGTM

[antoninbas]

/test-all

[antoninbas]

/test-conformance