Fix flaky e2e test due to mac address re-used #198
Conversation
|
Darn, need to understand this new namespace error first. Sorry for holding this PR hostage ... |
|
No problem, do you have a way to reproduce it? It's the first time I saw it before |
Not yet, I just saw this on a couple PRs in CI. |
|
I tried Kind v0.12.0 as used in the CI, but I could not even create a cluster for some reason. Probably it should be updated (not sure if it's related): https://github.com/k8snetworkplumbingwg/multus-cni/blob/a70da3556a41a04386e1f8049c2ea18f5feebc61/e2e/get_tools.sh#L8 |
|
Also, merging this k8snetworkplumbingwg/multus-cni#1208 might fix the first issue (timed out waiting for the condition) as the CI uses that file (e2e/templates/multus-daemonset-thick.yml.j2) to deploy Multus. |
|
Could you rebase ? @LionelJouin |
The mac addresses used during the e2e tests are now generated during the tests instead of being hard-coded. The hard-coded mac address was causing flacky tests probably due to the kernel refusing a new macvlan interface to be created with an already existing mac address.
LionelJouin
force-pushed
the
fix-flacky-e2e-test-mac
branch
from
6cc79e3
to
a80d03e
Compare
|
Done |
What this PR does / why we need it:
The mac addresses used during the e2e tests are now generated during the tests instead of being hard-coded.
The hard-coded mac address was causing flaky tests probably due to the kernel refusing a new macvlan interface to be created with an already existing mac address.
Which issue(s) this PR fixes:
Fixes #194 (1.)
Special notes for your reviewer (optional):