test:e2e: Add cri auth test #290
Conversation
Codecov ReportBase: 33.88% // Head: 33.88% // No change to project coverage 👍
Additional details and impacted files@@ Coverage Diff @@
## main #290 +/- ##
=======================================
Coverage 33.88% 33.88%
=======================================
Files 30 30
Lines 3223 3223
=======================================
Hits 1092 1092
Misses 2019 2019
Partials 112 112 Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
darfux
force-pushed
the
add-cri-auth-e2e
branch
3 times, most recently
from
779226f
to
a0d1580
Compare
|
Add e2e test for PR #282 /cc @changweige |
|
@liubin Do you have time to take a look at this PR too? |
| @@ -91,10 +89,8 @@ jobs: | |||
|
|
|||
| [plugins."io.containerd.grpc.v1.cri".registry.mirrors."${registry_ip}:5000"] | |||
| endpoint = ["http://${registry_ip}:5000"] | |||
| [plugins."io.containerd.grpc.v1.cri".registry.configs."${registry_ip}:5000".auth] | |||
| username = "${{ env.DOCKER_USER }}" | |||
| password = "${{ env.DOCKER_PASSWORD }}" | |||
There was a problem hiding this comment.
Is this not required?
I see the CI passed, but it seems both cri and kubeconf are useing the same node to run test.
You added image-service-endpoint to kubelet, but did not delete it when running kubeconfg test.
There was a problem hiding this comment.
From using-jobs-in-a-workflow and using-a-github-hosted-runner:
Each job runs in a runner environment specified by runs-on.
When the job begins, GitHub automatically provisions a new VM for that job.
I think each job will run in a standalone runner environment(VM) and don't share any data 🤔
Is this not required?
Under kubeconf case, kubelet can get the image secret from imagePullSecrets as well and pass it to containerd now.
There was a problem hiding this comment.
I‘ve tried to run a single kubeconf case: https://github.com/darfux/nydus-snapshotter/actions/runs/3701944536/jobs/6271709388 and it seems still OK. @liubin FYI😀
Make the original k8s-e2e workflow to be a reusable workflow template, which is used by cri case and kubeconf case with different `auth-type` input. Differences between cri case and kubeconf case: - CRI snapshotter spec needs extra containerd socket mount - CRI snapshotter spec has no cluster role for secrets - CRI snapshotter spec uses `--enable-cri-keychain` instead of `--enable-kubeconfig-keychain` - In the `Run E2E test` step, cri case needs to change the image service endpoint of kubelet to nydus-snapshotter Other changes: - Add `imagePullSecrets` to test pod spec and change it's namespace to `nydus-system`. So that kubelet can get the image secret under both cri&kubeconf cases. The auth info in the containerd config file is no longer needed and has been removed. - Add a `ps -ef` info log in the `Dump logs` step Signed-off-by: Li Yuxuan <liyuxuan.darfux@bytedance.com>
darfux
force-pushed
the
add-cri-auth-e2e
branch
from
a0d1580
to
23364c0
Compare
Make the original k8s-e2e workflow to be a reusable workflow template, which is used by cri case and kubeconf case with different
auth-typeinput.Differences between cri case and kubeconf case:
--enable-cri-keychaininstead of--enable-kubeconfig-keychainRun E2E teststep, cri case needs to change the image service endpoint of kubelet to nydus-snapshotterOther changes:
imagePullSecretsto test pod spec and change it's namespace tonydus-system. So that kubelet can get the image secret under both cri&kubeconf cases. The auth info in the containerd config file is no longer needed and has been removed.ps -efinfo log in theDump logsstepSigned-off-by: Li Yuxuan liyuxuan.darfux@bytedance.com