test: Use new test-verifier image in K8sVerifier #16231
Conversation
pchaigno
added
kind/bug/CI
There was a problem hiding this comment.
You could also remove test/k8sT/manifests/test-verifier.yaml from the image update scripts here:
Until now, K8sVerifier was using the
cilium-builderimage to build the datapath and runverifier-test.sh. However, with the new image builds, K8sVerifier is now the only consumer ofcilium-builderin the test VMs. If we replacecilium-builderwith a K8sVerifier-specific image, we can stop pre-pullingcilium-builderin the VM image.
It looks like the cilium-builder image is still used by another test manifest:
So I think we cannot stop pre-pulling it in the VM image yet after this PR. Or are we not running that test using the test VMs?
pchaigno
force-pushed
the
image-for-test-verifier
branch
from
4e8d403
to
585a7f0
Compare
pchaigno
force-pushed
the
image-for-test-verifier
branch
from
585a7f0
to
1691795
Compare
Until now, K8sVerifier was using the cilium-builder image to build the datapath and run verifier-test.sh. Having a K8sVerifier-specific image also allows us to include a patch for the tc binary, to increase the maximum size of the verifier log buffer. In the K8sVerifier test, we load all BPF programs in verbose mode, so the log buffer is always needed (vs. only in case of retry following a load error usually). A small log buffer can lead to a load failure that is actually a false positive (it's just the log buffer being too small and not an actual issue with the BPF program). Signed-off-by: Paul Chaignon <paul@cilium.io>
pchaigno
force-pushed
the
image-for-test-verifier
branch
from
1691795
to
4b1bb3a
Compare
pchaigno
changed the title
|
test-1.20-4.19 |
|
test-1.21-4.9 |
|
test-1.16-netnext |
|
test-1.19-5.4 |
|
k8s-1.19-kernel-5.4 hit known flake #15575. Other CI jobs are passing. Reviews are in. Marking as ready to merge. |
pchaigno
added
the
ready-to-merge
Until now, K8sVerifier was using the cilium-builder image to build the datapath and run verifier-test.sh. Having a K8sVerifier-specific image also allows us to include a patch for the tc binary, to increase the maximum size of the verifier log buffer. In the K8sVerifier test, we load all BPF programs in verbose mode, so the log buffer is always needed (vs. only in case of retry following a load error usually). A small log buffer can lead to a load failure that is actually a false positive (it's just the log buffer being too small and not an actual issue with the BPF program).