🌱 Change the experimental-e2e to use a two-node kind cluster #2382
Conversation
✅ Deploy Preview for olmv1 ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
tmshort
force-pushed
the
multi-node-kind
branch
from
f4ea6ca to
fb4929b
Compare
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #2382 +/- ##
==========================================
+ Coverage 72.87% 73.02% +0.14%
==========================================
Files 98 100 +2
Lines 7581 7641 +60
==========================================
+ Hits 5525 5580 +55
- Misses 1622 1624 +2
- Partials 434 437 +3
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
In order to fully support multiple replicas, we need to be able to run our tests in a multi-node environment, but we don't _always_ want to run in a multi-node test environment. Update the experimental-e2e to run a 2-node kind cluster (both control- plane). Update the `kind-load` recipe to directly load a docker image via `load docker-image`, since `load image-archive` has issues with multi-node clusters. Signed-off-by: Todd Short <tshort@redhat.com>
tmshort
force-pushed
the
multi-node-kind
branch
from
fb4929b to
32e6211
Compare
| @@ -0,0 +1,45 @@ | |||
| apiVersion: kind.x-k8s.io/v1alpha4 | |||
There was a problem hiding this comment.
nit: kind-config-experimental.yaml sounds to me like some sort of experimental kind config, but actually it is just a two-node config. Perhaps we could reflect that in the filename?
BTW, does this file need to be in the project root?
There was a problem hiding this comment.
It's the same location as the other kind config; keep similar files together.
There was a problem hiding this comment.
does this file need to be in the project root
Now that there are multiple kind config files at play, it makes sense to me to bury this in a subdirectory somewhere.
There was a problem hiding this comment.
That's fair, and easy.
| extraMounts: | ||
| - hostPath: ./hack/kind-config/containerd/certs.d | ||
| containerPath: /etc/containerd/certs.d | ||
| - role: control-plane |
There was a problem hiding this comment.
we do not need another control-plane node, a worker node could be just fine. Furthermore, each control plane node runs a copy of control plane pods (etcd, apiserver, scheduler, controller-manager) doubling the resources consumed by kind. Additional worker node keeps the resource usage on previous level.
There was a problem hiding this comment.
This is on purpose,. operator-controller and catalogd are supposed to run only on control-plane nodes; not worker nodes. It's part of what we want to test. This is also only for the experimental-e2e, so it's not used for normal run-time.
The reason we use the archive variant for image loading is to support contributors that use podman instead of docker. Will this change break their workflows? |
I know, but the Issues: kubernetes-sigs/kind#3105 (closed and dup'd to: kubernetes-sigs/kind#2038) |
And now I'm trying without my changes, and it's failing with just podman... So, it looks as though we're already broken... |
3 participants
In order to fully support multiple replicas, we need to be able to run our tests in a multi-node environment, but we don't always want to run in a multi-node test environment.
Update the experimental-e2e to run a 2-node kind cluster (both control- plane).
Update the
kind-loadrecipe to directly load a docker image viaload docker-image, sinceload image-archivehas issues with multi-node clusters.Description
Reviewer Checklist