test/e2e: Run in parallel #76

RamLavi · 2024-11-21T11:32:18Z

What this PR does / why we need it:
This PR is running the e2e tests in parallel, as tests should be independent of each other.
The amount of threads depends on the number of CPUs available in the machine running the CI.
Running it on the PR should increase CI time, and potentially expose bugs.

e2e run example: E2E_TEST_ARGS='--focus="should keep ips after live migration"' make test-e2e

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #

Special notes for your reviewer:

Release note:

NONE

RamLavi · 2024-12-19T09:59:37Z

@maiqueb looking at the e2e test failing, it seems like prior (and also after) to migration the primary UDN virt-launcher pod is not getting the appropriate network-status (logs):

2024-12-18T09:08:33.5592345Z   RAM B4 Migration vmi alpine-908896f1e virtLauncherPod virt-launcher-alpine-908896f1e-h2nb9 Annotations map[descheduler.alpha.kubernetes.io/request-evict-only: k8s.ovn.org/pod-networks:{"default":{"ip_addresses":["10.244.1.15/24","fd00:10:244:2::f/64"],"mac_address":"0a:58:0a:f4:01:0f","gateway_ips":["10.244.1.1","fd00:10:244:2::1"],"routes":[{"dest":"10.244.0.0/16","nextHop":"10.244.1.1"},{"dest":"10.96.0.0/16","nextHop":"10.244.1.1"},{"dest":"169.254.0.5/32","nextHop":"10.244.1.1"},{"dest":"100.64.0.0/16","nextHop":"10.244.1.1"},{"dest":"fd00:10:244::/48","nextHop":"fd00:10:244:2::1"},{"dest":"fd00:10:96::/112","nextHop":"fd00:10:244:2::1"},{"dest":"fd69::5/128","nextHop":"fd00:10:244:2::1"},{"dest":"fd98::/64","nextHop":"fd00:10:244:2::1"}],"role":"primary"},"testns-30ce1396d/l2-net-attach-def":{"ip_addresses":["10.100.200.3/24"],"mac_address":"0a:58:0a:64:c8:03","gateway_ips":["10.100.200.1"],"routes":[{"dest":"10.96.0.0/16","nextHop":"10.100.200.1"},{"dest":"100.65.0.0/16","nextHop":"10.100.200.1"}],"ip_address":"10.100.200.3/24","gateway_ip":"10.100.200.1","tunnel_id":4,"role":"primary"}} k8s.ovn.org/primary-udn-ipamclaim:alpine-908896f1e.pod k8s.v1.cni.cncf.io/network-status:[{
2024-12-18T09:08:33.5597745Z       "name": "ovn-kubernetes",
2024-12-18T09:08:33.5598207Z       "interface": "eth0",
2024-12-18T09:08:33.5598567Z       "ips": [
2024-12-18T09:08:33.5598959Z           "10.244.1.15",
2024-12-18T09:08:33.5599436Z           "fd00:10:244:2::f"
2024-12-18T09:08:33.5599819Z       ],
2024-12-18T09:08:33.5600197Z       "mac": "0a:58:0a:f4:01:0f",
2024-12-18T09:08:33.5600463Z       "default": true,
2024-12-18T09:08:33.5600668Z       "dns": {}
2024-12-18T09:08:33.5603199Z   }] kubectl.kubernetes.io/default-container:compute kubevirt.io/domain:alpine-908896f1e kubevirt.io/migrationTransportUnix:true kubevirt.io/vm-generation:1 post.hook.backup.velero.io/command:["/usr/bin/virt-freezer", "--unfreeze", "--name", "alpine-908896f1e", "--namespace", "testns-30ce1396d"] post.hook.backup.velero.io/container:compute pre.hook.backup.velero.io/command:["/usr/bin/virt-freezer", "--freeze", "--name", "alpine-908896f1e", "--namespace", "testns-30ce1396d"] pre.hook.backup.velero.io/container:compute]
2024-12-18T09:08:33.5606414Z

Can we attribute this issue to the OVNK race you talked about? OR is it a new issue we need to check?

maiqueb · 2024-12-19T12:08:33Z

@maiqueb looking at the e2e test failing, it seems like prior (and also after) to migration the primary UDN virt-launcher pod is not getting the appropriate network-status (logs):

2024-12-18T09:08:33.5592345Z   RAM B4 Migration vmi alpine-908896f1e virtLauncherPod virt-launcher-alpine-908896f1e-h2nb9 Annotations map[descheduler.alpha.kubernetes.io/request-evict-only: k8s.ovn.org/pod-networks:{"default":{"ip_addresses":["10.244.1.15/24","fd00:10:244:2::f/64"],"mac_address":"0a:58:0a:f4:01:0f","gateway_ips":["10.244.1.1","fd00:10:244:2::1"],"routes":[{"dest":"10.244.0.0/16","nextHop":"10.244.1.1"},{"dest":"10.96.0.0/16","nextHop":"10.244.1.1"},{"dest":"169.254.0.5/32","nextHop":"10.244.1.1"},{"dest":"100.64.0.0/16","nextHop":"10.244.1.1"},{"dest":"fd00:10:244::/48","nextHop":"fd00:10:244:2::1"},{"dest":"fd00:10:96::/112","nextHop":"fd00:10:244:2::1"},{"dest":"fd69::5/128","nextHop":"fd00:10:244:2::1"},{"dest":"fd98::/64","nextHop":"fd00:10:244:2::1"}],"role":"primary"},"testns-30ce1396d/l2-net-attach-def":{"ip_addresses":["10.100.200.3/24"],"mac_address":"0a:58:0a:64:c8:03","gateway_ips":["10.100.200.1"],"routes":[{"dest":"10.96.0.0/16","nextHop":"10.100.200.1"},{"dest":"100.65.0.0/16","nextHop":"10.100.200.1"}],"ip_address":"10.100.200.3/24","gateway_ip":"10.100.200.1","tunnel_id":4,"role":"primary"}} k8s.ovn.org/primary-udn-ipamclaim:alpine-908896f1e.pod k8s.v1.cni.cncf.io/network-status:[{
2024-12-18T09:08:33.5597745Z       "name": "ovn-kubernetes",
2024-12-18T09:08:33.5598207Z       "interface": "eth0",
2024-12-18T09:08:33.5598567Z       "ips": [
2024-12-18T09:08:33.5598959Z           "10.244.1.15",
2024-12-18T09:08:33.5599436Z           "fd00:10:244:2::f"
2024-12-18T09:08:33.5599819Z       ],
2024-12-18T09:08:33.5600197Z       "mac": "0a:58:0a:f4:01:0f",
2024-12-18T09:08:33.5600463Z       "default": true,
2024-12-18T09:08:33.5600668Z       "dns": {}
2024-12-18T09:08:33.5603199Z   }] kubectl.kubernetes.io/default-container:compute kubevirt.io/domain:alpine-908896f1e kubevirt.io/migrationTransportUnix:true kubevirt.io/vm-generation:1 post.hook.backup.velero.io/command:["/usr/bin/virt-freezer", "--unfreeze", "--name", "alpine-908896f1e", "--namespace", "testns-30ce1396d"] post.hook.backup.velero.io/container:compute pre.hook.backup.velero.io/command:["/usr/bin/virt-freezer", "--freeze", "--name", "alpine-908896f1e", "--namespace", "testns-30ce1396d"] pre.hook.backup.velero.io/container:compute]
2024-12-18T09:08:33.5606414Z

Can we attribute this issue to the OVNK race you talked about? OR is it a new issue we need to check?

It could be.

You'll need to check the logs of the ovnkube-control plane and ensure that for that pod it failed to find the primary UDN network to be sure.

RamLavi · 2024-12-19T13:29:19Z

@maiqueb looking at the e2e test failing, it seems like prior (and also after) to migration the primary UDN virt-launcher pod is not getting the appropriate network-status (logs):

2024-12-18T09:08:33.5592345Z   RAM B4 Migration vmi alpine-908896f1e virtLauncherPod virt-launcher-alpine-908896f1e-h2nb9 Annotations map[descheduler.alpha.kubernetes.io/request-evict-only: k8s.ovn.org/pod-networks:{"default":{"ip_addresses":["10.244.1.15/24","fd00:10:244:2::f/64"],"mac_address":"0a:58:0a:f4:01:0f","gateway_ips":["10.244.1.1","fd00:10:244:2::1"],"routes":[{"dest":"10.244.0.0/16","nextHop":"10.244.1.1"},{"dest":"10.96.0.0/16","nextHop":"10.244.1.1"},{"dest":"169.254.0.5/32","nextHop":"10.244.1.1"},{"dest":"100.64.0.0/16","nextHop":"10.244.1.1"},{"dest":"fd00:10:244::/48","nextHop":"fd00:10:244:2::1"},{"dest":"fd00:10:96::/112","nextHop":"fd00:10:244:2::1"},{"dest":"fd69::5/128","nextHop":"fd00:10:244:2::1"},{"dest":"fd98::/64","nextHop":"fd00:10:244:2::1"}],"role":"primary"},"testns-30ce1396d/l2-net-attach-def":{"ip_addresses":["10.100.200.3/24"],"mac_address":"0a:58:0a:64:c8:03","gateway_ips":["10.100.200.1"],"routes":[{"dest":"10.96.0.0/16","nextHop":"10.100.200.1"},{"dest":"100.65.0.0/16","nextHop":"10.100.200.1"}],"ip_address":"10.100.200.3/24","gateway_ip":"10.100.200.1","tunnel_id":4,"role":"primary"}} k8s.ovn.org/primary-udn-ipamclaim:alpine-908896f1e.pod k8s.v1.cni.cncf.io/network-status:[{
2024-12-18T09:08:33.5597745Z       "name": "ovn-kubernetes",
2024-12-18T09:08:33.5598207Z       "interface": "eth0",
2024-12-18T09:08:33.5598567Z       "ips": [
2024-12-18T09:08:33.5598959Z           "10.244.1.15",
2024-12-18T09:08:33.5599436Z           "fd00:10:244:2::f"
2024-12-18T09:08:33.5599819Z       ],
2024-12-18T09:08:33.5600197Z       "mac": "0a:58:0a:f4:01:0f",
2024-12-18T09:08:33.5600463Z       "default": true,
2024-12-18T09:08:33.5600668Z       "dns": {}
2024-12-18T09:08:33.5603199Z   }] kubectl.kubernetes.io/default-container:compute kubevirt.io/domain:alpine-908896f1e kubevirt.io/migrationTransportUnix:true kubevirt.io/vm-generation:1 post.hook.backup.velero.io/command:["/usr/bin/virt-freezer", "--unfreeze", "--name", "alpine-908896f1e", "--namespace", "testns-30ce1396d"] post.hook.backup.velero.io/container:compute pre.hook.backup.velero.io/command:["/usr/bin/virt-freezer", "--freeze", "--name", "alpine-908896f1e", "--namespace", "testns-30ce1396d"] pre.hook.backup.velero.io/container:compute]
2024-12-18T09:08:33.5606414Z

Can we attribute this issue to the OVNK race you talked about? OR is it a new issue we need to check?

It could be.

You'll need to check the logs of the ovnkube-control plane and ensure that for that pod it failed to find the primary UDN network to be sure.

I don't see any pod fails, but are you sure we should find a "pod fail"? I mean, it did find a primary network, it was just the wrong one.. In any case, this is very helpful, I've also asked on the race bug to know more information..

maiqueb · 2024-12-19T13:32:47Z

@maiqueb looking at the e2e test failing, it seems like prior (and also after) to migration the primary UDN virt-launcher pod is not getting the appropriate network-status (logs):

2024-12-18T09:08:33.5592345Z   RAM B4 Migration vmi alpine-908896f1e virtLauncherPod virt-launcher-alpine-908896f1e-h2nb9 Annotations map[descheduler.alpha.kubernetes.io/request-evict-only: k8s.ovn.org/pod-networks:{"default":{"ip_addresses":["10.244.1.15/24","fd00:10:244:2::f/64"],"mac_address":"0a:58:0a:f4:01:0f","gateway_ips":["10.244.1.1","fd00:10:244:2::1"],"routes":[{"dest":"10.244.0.0/16","nextHop":"10.244.1.1"},{"dest":"10.96.0.0/16","nextHop":"10.244.1.1"},{"dest":"169.254.0.5/32","nextHop":"10.244.1.1"},{"dest":"100.64.0.0/16","nextHop":"10.244.1.1"},{"dest":"fd00:10:244::/48","nextHop":"fd00:10:244:2::1"},{"dest":"fd00:10:96::/112","nextHop":"fd00:10:244:2::1"},{"dest":"fd69::5/128","nextHop":"fd00:10:244:2::1"},{"dest":"fd98::/64","nextHop":"fd00:10:244:2::1"}],"role":"primary"},"testns-30ce1396d/l2-net-attach-def":{"ip_addresses":["10.100.200.3/24"],"mac_address":"0a:58:0a:64:c8:03","gateway_ips":["10.100.200.1"],"routes":[{"dest":"10.96.0.0/16","nextHop":"10.100.200.1"},{"dest":"100.65.0.0/16","nextHop":"10.100.200.1"}],"ip_address":"10.100.200.3/24","gateway_ip":"10.100.200.1","tunnel_id":4,"role":"primary"}} k8s.ovn.org/primary-udn-ipamclaim:alpine-908896f1e.pod k8s.v1.cni.cncf.io/network-status:[{
2024-12-18T09:08:33.5597745Z       "name": "ovn-kubernetes",
2024-12-18T09:08:33.5598207Z       "interface": "eth0",
2024-12-18T09:08:33.5598567Z       "ips": [
2024-12-18T09:08:33.5598959Z           "10.244.1.15",
2024-12-18T09:08:33.5599436Z           "fd00:10:244:2::f"
2024-12-18T09:08:33.5599819Z       ],
2024-12-18T09:08:33.5600197Z       "mac": "0a:58:0a:f4:01:0f",
2024-12-18T09:08:33.5600463Z       "default": true,
2024-12-18T09:08:33.5600668Z       "dns": {}
2024-12-18T09:08:33.5603199Z   }] kubectl.kubernetes.io/default-container:compute kubevirt.io/domain:alpine-908896f1e kubevirt.io/migrationTransportUnix:true kubevirt.io/vm-generation:1 post.hook.backup.velero.io/command:["/usr/bin/virt-freezer", "--unfreeze", "--name", "alpine-908896f1e", "--namespace", "testns-30ce1396d"] post.hook.backup.velero.io/container:compute pre.hook.backup.velero.io/command:["/usr/bin/virt-freezer", "--freeze", "--name", "alpine-908896f1e", "--namespace", "testns-30ce1396d"] pre.hook.backup.velero.io/container:compute]
2024-12-18T09:08:33.5606414Z

Can we attribute this issue to the OVNK race you talked about? OR is it a new issue we need to check?

It could be.
You'll need to check the logs of the ovnkube-control plane and ensure that for that pod it failed to find the primary UDN network to be sure.

I don't see any pod fails, but are you sure we should find a "pod fail"? I mean, it did find a primary network, it was just the wrong one.. In any case, this is very helpful, I've also asked on the race bug to know more information..

So that's what you need to find: when it returns the active network for the namespace, which one did it find ?

It should have found the primary UDN, not the default one. Can you print the relevant log snippet ?

RamLavi · 2024-12-31T20:00:42Z

After some digging on OVNK, I realized the network is being reconciled. The reason is that the network name in the tests is the same. In order to separate the test and run them in parallel - I changed the network names to be unique.

maiqueb

Seems OK to me, but I wonder if / how we can still indicate which tests we want to run.

maiqueb · 2025-01-08T10:34:39Z

Makefile

 	export KUBECONFIG=${KUBECONFIG} && \
 	export PATH=$$(pwd)/.output/ovn-kubernetes/bin:$${PATH} && \
 	export REPORT_PATH=$$(pwd)/.output/ && \
 	cd test/e2e && \
-	go test -test.v --ginkgo.v --test.timeout=${E2E_TEST_TIMEOUT} ${E2E_TEST_ARGS} --ginkgo.junit-report=$${REPORT_PATH}/test-e2e.junit.xml
+	$(GINKGO) -v --timeout=${E2E_TEST_TIMEOUT} --junit-report=$${REPORT_PATH}/test-e2e.junit.xml


how will the user specify a test subset to run ?

You're right. I re-introduced the E2E_TEST_ARGS flag.
DONE

RamLavi · 2025-01-08T13:29:08Z

Change: re-introduced the E2E_TEST_ARGS flag.

Moving to use ginkgo tool instead of go test. This is done in order to use the parallel ginkgo parameter that is not supported on "go test" tool. Signed-off-by: Ram Lavi <[email protected]>

The e2e tests currently randomize the namespaces, but the network name inside the NADs is the same, creating dependency between the tests. In order to runthe tests in parallel, a change that will be introduced in future commit - randomizing the network names as well. Signed-off-by: Ram Lavi <[email protected]>

RamLavi · 2025-01-08T13:29:33Z

Change: Rebase

maiqueb

@RamLavi did you check this does the trick locally ?

No way it shouldn't afaict, but still, please paste an example of how to invoke it both in the appropriate commit msg and in the PR's description.

Thank you !

RamLavi · 2025-01-08T13:31:58Z

@RamLavi did you check this does the trick locally ?

I run it on zeus33. good enough right?

No way it shouldn't afaict, but still, please paste an example of how to invoke it both in the appropriate commit msg and in the PR's description.

The usage is the same: make test-e2e. Should I mention it?

The way it works is the that when the parallel flag is set, it auto-finds how many threads it can open, and runs with it. On Zeus33 - it's 10+ threads, so the CI takes ~3m. On github CI, it's more like ~10m.

maiqueb · 2025-01-08T13:35:57Z

@RamLavi did you check this does the trick locally ?

I run it on zeus33. good enough right?

No way it shouldn't afaict, but still, please paste an example of how to invoke it both in the appropriate commit msg and in the PR's description.

The usage is the same: make test-e2e. Should I mention it?

I mean regarding the flag. If you want to filter some tests, do you need to use a different flag ? Can you check locally if you need to ? I have the slight recollection it isn't exactly the same command. BUT I might be wrong.

@qinqon could you chime in here ? Thanks in advance.

RamLavi · 2025-01-08T18:10:23Z

@RamLavi did you check this does the trick locally ?

I run it on zeus33. good enough right?

No way it shouldn't afaict, but still, please paste an example of how to invoke it both in the appropriate commit msg and in the PR's description.

The usage is the same: make test-e2e. Should I mention it?

I mean regarding the flag. If you want to filter some tests, do you need to use a different flag ? Can you check locally if you need to ? I have the slight recollection it isn't exactly the same command. BUT I might be wrong.

@qinqon could you chime in here ? Thanks in advance.

Using the general E2E_TEST_ARGS env var allows us to add whatever flags we wish. For ginkgo the relevant flags are --skip and --focus. I tried focus and it works:

# E2E_TEST_ARGS='--focus="should keep ips after live migration"' make test-e2e
export KUBECONFIG=/root/github.com/kubevirt/ipam-extensions/.output/kubeconfig && \
export PATH=$(pwd)/.output/ovn-kubernetes/bin:${PATH} && \
export REPORT_PATH=$(pwd)/.output/ && \
cd test/e2e && \
/root/github.com/kubevirt/ipam-extensions/bin/ginkgo-v2.22.0 -v --timeout="1h" --junit-report=${REPORT_PATH}/test-e2e.junit.xml --focus='"should keep ips after live migration"'
...
Will run 4 of 20 specs
...

but that's not a new env var.

maiqueb · 2025-01-08T21:41:01Z

@RamLavi did you check this does the trick locally ?

I run it on zeus33. good enough right?

No way it shouldn't afaict, but still, please paste an example of how to invoke it both in the appropriate commit msg and in the PR's description.

The usage is the same: make test-e2e. Should I mention it?

I mean regarding the flag. If you want to filter some tests, do you need to use a different flag ? Can you check locally if you need to ? I have the slight recollection it isn't exactly the same command. BUT I might be wrong.
@qinqon could you chime in here ? Thanks in advance.

Using the general E2E_TEST_ARGS env var allows us to add whatever flags we wish. For ginkgo the relevant flags are --skip and --focus. I tried focus and it works:
# E2E_TEST_ARGS='--focus="should keep ips after live migration"' make test-e2e
export KUBECONFIG=/root/github.com/kubevirt/ipam-extensions/.output/kubeconfig && \
export PATH=$(pwd)/.output/ovn-kubernetes/bin:${PATH} && \
export REPORT_PATH=$(pwd)/.output/ && \
cd test/e2e && \
/root/github.com/kubevirt/ipam-extensions/bin/ginkgo-v2.22.0 -v --timeout="1h" --junit-report=${REPORT_PATH}/test-e2e.junit.xml --focus='"should keep ips after live migration"'
...
Will run 4 of 20 specs
...
but that's not a new env var.

Sure, but for us to keep it's current behavior, the value in it must now be different.

All good. Could you add this E2E_TEST_ARGS='--focus="should keep ips after live migration"' make test-e2e cmd to the PR description and the git commit msg ?

Then, lgtm / approve / merge :)

In order to manage failed tests artifacts, the process# is added to the log file name. e2e run example: `E2E_TEST_ARGS='--focus="should keep ips after live migration"' make test-e2e` Signed-off-by: Ram Lavi <[email protected]>

RamLavi · 2025-01-09T07:30:07Z

Change: Updated commit desc

maiqueb

/approve

Thank you.

kubevirt-bot · 2025-01-09T08:29:43Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: maiqueb

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

~~OWNERS~~ [maiqueb]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

maiqueb · 2025-01-09T08:29:59Z

/hold

test/env/generate.go

RamLavi · 2025-01-09T09:04:54Z

/hold cancel

kubevirt-bot added the dco-signoff: yes Indicates the PR's author has DCO signed all their commits. label Nov 21, 2024

kubevirt-bot requested review from maiqueb and oshoval November 21, 2024 11:32

kubevirt-bot added the size/S label Nov 21, 2024

RamLavi changed the title ~~spike: Run e2e tests in paralel~~ [DNM] spike: Run e2e tests in paralel Nov 21, 2024

kubevirt-bot added size/M and removed size/S labels Nov 24, 2024

RamLavi force-pushed the parallel branch from b789ca2 to 17adac3 Compare November 24, 2024 09:03

kubevirt-bot added size/S and removed size/M labels Nov 24, 2024

kubevirt-bot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Dec 17, 2024

RamLavi force-pushed the parallel branch from 17adac3 to 93775f3 Compare December 18, 2024 06:28

kubevirt-bot added size/XXL and removed needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. size/S labels Dec 18, 2024

RamLavi force-pushed the parallel branch from 93775f3 to 7843da3 Compare December 18, 2024 08:48

RamLavi force-pushed the parallel branch from 7843da3 to 56b240b Compare December 31, 2024 19:58

kubevirt-bot added size/S and removed size/XXL labels Dec 31, 2024

RamLavi changed the title ~~[DNM] spike: Run e2e tests in paralel~~ test/e2e: Run in paralel Dec 31, 2024

RamLavi changed the title ~~test/e2e: Run in paralel~~ test/e2e: Run in parallel Dec 31, 2024

RamLavi force-pushed the parallel branch 2 times, most recently from 8e794c9 to 127686b Compare January 6, 2025 07:01

maiqueb requested changes Jan 8, 2025

View reviewed changes

kubevirt-bot assigned maiqueb Jan 8, 2025

RamLavi force-pushed the parallel branch from 127686b to 2b47b7d Compare January 8, 2025 13:27

RamLavi added 2 commits January 8, 2025 15:29

Makefile, test-e2e: Change to use ginkgo tool

1ee9a54

Moving to use ginkgo tool instead of go test. This is done in order to use the parallel ginkgo parameter that is not supported on "go test" tool. Signed-off-by: Ram Lavi <[email protected]>

RamLavi force-pushed the parallel branch from 2b47b7d to 314f474 Compare January 8, 2025 13:29

maiqueb reviewed Jan 8, 2025

View reviewed changes

e2e, persistent-ips: Added parallel flag

9399992

In order to manage failed tests artifacts, the process# is added to the log file name. e2e run example: `E2E_TEST_ARGS='--focus="should keep ips after live migration"' make test-e2e` Signed-off-by: Ram Lavi <[email protected]>

RamLavi force-pushed the parallel branch from 314f474 to 9399992 Compare January 9, 2025 06:19

maiqueb approved these changes Jan 9, 2025

View reviewed changes

kubevirt-bot added the lgtm Indicates that a PR is ready to be merged. label Jan 9, 2025

kubevirt-bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jan 9, 2025

kubevirt-bot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Jan 9, 2025

maiqueb reviewed Jan 9, 2025

View reviewed changes

test/env/generate.go Show resolved Hide resolved

kubevirt-bot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Jan 9, 2025

kubevirt-bot merged commit e450c8e into kubevirt:main Jan 9, 2025
4 checks passed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

test/e2e: Run in parallel #76

test/e2e: Run in parallel #76

RamLavi commented Nov 21, 2024 •

edited

Loading

RamLavi commented Dec 19, 2024

maiqueb commented Dec 19, 2024

RamLavi commented Dec 19, 2024

maiqueb commented Dec 19, 2024 •

edited

Loading

RamLavi commented Dec 31, 2024

maiqueb left a comment

maiqueb Jan 8, 2025

RamLavi Jan 8, 2025

RamLavi commented Jan 8, 2025

RamLavi commented Jan 8, 2025

maiqueb left a comment

RamLavi commented Jan 8, 2025 •

edited

Loading

maiqueb commented Jan 8, 2025

RamLavi commented Jan 8, 2025 •

edited

Loading

maiqueb commented Jan 8, 2025

RamLavi commented Jan 9, 2025

maiqueb left a comment

kubevirt-bot commented Jan 9, 2025

maiqueb commented Jan 9, 2025

RamLavi commented Jan 9, 2025

test/e2e: Run in parallel #76

test/e2e: Run in parallel #76

Conversation

RamLavi commented Nov 21, 2024 • edited Loading

RamLavi commented Dec 19, 2024

maiqueb commented Dec 19, 2024

RamLavi commented Dec 19, 2024

maiqueb commented Dec 19, 2024 • edited Loading

RamLavi commented Dec 31, 2024

maiqueb left a comment

Choose a reason for hiding this comment

maiqueb Jan 8, 2025

Choose a reason for hiding this comment

RamLavi Jan 8, 2025

Choose a reason for hiding this comment

RamLavi commented Jan 8, 2025

RamLavi commented Jan 8, 2025

maiqueb left a comment

Choose a reason for hiding this comment

RamLavi commented Jan 8, 2025 • edited Loading

maiqueb commented Jan 8, 2025

RamLavi commented Jan 8, 2025 • edited Loading

maiqueb commented Jan 8, 2025

RamLavi commented Jan 9, 2025

maiqueb left a comment

Choose a reason for hiding this comment

kubevirt-bot commented Jan 9, 2025

maiqueb commented Jan 9, 2025

RamLavi commented Jan 9, 2025

RamLavi commented Nov 21, 2024 •

edited

Loading

maiqueb commented Dec 19, 2024 •

edited

Loading

RamLavi commented Jan 8, 2025 •

edited

Loading

RamLavi commented Jan 8, 2025 •

edited

Loading