fix: `Eventually()` missing `Should()` statement and sync error #11101

jcanocan · 2024-01-29T12:10:40Z

What this PR does / why we need it:
The linter enforces the usage of Should() statements when a Eventually check is used.
It adds the missing Eventually() statements Should() checks.

Also, DeferCleanup has been dropped in favor of defer. The resetToDefaultConfig() is called before the test DeferCleanup, creating the following error:

  [FAILED] in [AfterEach] - tests/utils.go:1601 @ 01/29/24 15:32:28.576
  << Timeline
  [FAILED] Timed out after 10.001s.
  Unexpected error:
      <*errors.errorString | 0xc006203230>: 
      resource & config versions (5548 and 4736 respectively) are not as expected. component: "virt-handler", pod: "virt-handler-zdv7f" 
      {
          s: "resource & config versions (5548 and 4736 respectively) are not as expected. component: \"virt-handler\", pod: \"virt-handler-zdv7f\" ",
      }
  occurred
  In [AfterEach] at: tests/utils.go:1601 @ 01/29/24 15:32:28.576
  Full Stack Trace
    kubevirt.io/kubevirt/tests.resetToDefaultConfig()
        tests/utils.go:1601 +0x85
    kubevirt.io/kubevirt/tests.TestCleanup()
        tests/utils.go:113 +0x6f
    kubevirt.io/kubevirt/tests_test.glob..func21()
        tests/tests_suite_test.go:108 +0xf

This is because the virt-handler will not be ready (intentionally for the purposes of the test), and the resetToDefaultConfig() will force the virt-handler to reconcile, which will fail, but the virt-handler resourceVersion will be updated. Therefore, the Kubevirt object will be out of sync.

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:

Checklist

This checklist is not enforcing, but it's a reminder of items that could be relevant to every PR.
Approvers are expected to review this list.

Design: A design document was considered and is present (link) or not required
PR: The PR description is expressive enough and will help future contributors
Code: Write code that humans can understand and Keep it simple
Refactor: You have left the code cleaner than you found it (Boy Scout Rule)
Upgrade: Impact of this change on upgrade flows was considered and addressed if required
Testing: New code requires new unit tests. New features and bug fixes require at least on e2e test
Documentation: A user-guide update was considered and is present (link) or not required. You want a user-guide update if it's a user facing feature / API change.
Community: Announcement to kubevirt-dev was considered

Release note:

NONE

xpivarc

/approve

kubevirt-bot · 2024-01-29T12:11:58Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: xpivarc

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:

~~tests/OWNERS~~ [xpivarc]

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

kubevirt-commenter-bot · 2024-01-29T12:12:02Z

Required labels detected, running phase 2 presubmits:
/test pull-kubevirt-e2e-kind-1.27-sriov
/test pull-kubevirt-e2e-k8s-1.29-ipv6-sig-network
/test pull-kubevirt-e2e-k8s-1.27-sig-network
/test pull-kubevirt-e2e-k8s-1.27-sig-storage
/test pull-kubevirt-e2e-k8s-1.27-sig-compute
/test pull-kubevirt-e2e-k8s-1.27-sig-operator
/test pull-kubevirt-e2e-k8s-1.28-sig-network
/test pull-kubevirt-e2e-k8s-1.28-sig-storage
/test pull-kubevirt-e2e-k8s-1.28-sig-compute
/test pull-kubevirt-e2e-k8s-1.28-sig-operator

xpivarc · 2024-01-29T14:08:50Z

/hold
flakes

xpivarc · 2024-01-30T07:04:22Z

tests/vm_test.go

+				// FIXME: this is just a test to see if the flakiness is reduced
+				migrationBandwidth := resource.MustParse("1Mi")
+				kv := util.GetCurrentKv(virtClient)
+				kv.Spec.Configuration.MigrationConfiguration = &v1.MigrationConfiguration{
+					BandwidthPerMigration: &migrationBandwidth,
+				}
+				kv = testsuite.UpdateKubeVirtConfigValue(kv.Spec.Configuration)
+				tests.WaitForConfigToBePropagatedToComponent("kubevirt.io=virt-handler", kv.ResourceVersion, tests.ExpectResourceVersionToBeLessEqualThanConfigVersion, 120*time.Second)


@jcanocan Please remove this.

As far as I was able to test, this has been the key piece to stabilize the test. I've taken it from this other test:

kubevirt/tests/virt_control_plane_test.go

Lines 271 to 279 in 7cfc625

By("changing a setting and ensuring that the config update watcher eventually resumes and picks it up")

migrationBandwidth := resource.MustParse("1Mi")

kv := util.GetCurrentKv(virtCli)

kv.Spec.Configuration.MigrationConfiguration = &k6sv1.MigrationConfiguration{

BandwidthPerMigration: &migrationBandwidth,

}

kv = testsuite.UpdateKubeVirtConfigValue(kv.Spec.Configuration)

tests.WaitForConfigToBePropagatedToComponent("kubevirt.io=virt-handler", kv.ResourceVersion, tests.ExpectResourceVersionToBeLessEqualThanConfigVersion, 60*time.Second)

})

Dropped the FIXME comment.

I will give the flakes line a couple of extra runs to be sure.

EdDev · 2024-01-30T07:28:18Z

tests/vm_test.go


-			DeferCleanup(func() {
+			defer func() {
 				libpod.DeleteKubernetesApiBlackhole(getHandlerNodePod(virtClient, nodeName), componentName)


These kind of hacks are causing the whole tests suite to collapse on itself.

There is nothing safe that can be done to fix something like this and I hope to see this whole test removed.

But this is not really related to this fix. I just think the fix is to remove it.

Dropped the usage of defer for this purpose. I agree, it's not elegant. Thanks for the input.

I was actually referring to hacking the virt-handler network.

It is indeed nicer without the defer, but what actually is done here is very risky and IMO does not fit our tests.
If for some reason the pod state is not fixed (e.g. the route is not deleted), we are left with a broken cluster and following tests will flake in a hard to understand manner.

IMO we should not have such tests around, we cannot cover every scenario in a reasonable safe manner.
Our resources are limited, tests are long and flaky enough not to risk them further.
If someone thinks it is worth the resources and risk, it would be better to allocate a dedicate job for such tests. I think reality dictates that we need to manage our e2e tests and focus on the main functionality and leave the edge scenarios to the community to detect (reporting bugs, running more tests on D/S projects and contributing back).

There is precedence for destructive tests, if we want to run them on separate lanes or not have them at all, the decision should be made in wider consensus + maintainers.

I am not sure what is better about the AfterEach, other than it is wrong afaik.

Note: I don't agree. This is not a conformance test and if anything this does fail loudly!

Well, I disagree with the presence of cluster-level destructive tests and I reasoned about it in the prev message. The fact that they exist is not a sign of them being good for the overall project.

This is not a conformance test and if anything this does fail loudly!

If tests like this fail, they either mess up all following tests or destabilize the cluster in ways we may not predict.

There is precedence for destructive tests, if we want to run them on separate lanes or not have them at all, the decision should be made in wider consensus + maintainers.

Well, I disagree with the presence of cluster-level destructive tests and I reasoned about it in the prev message. The fact that they exist is not a sign of them being good for the overall project.

This is not a conformance test and if anything this does fail loudly!

If tests like this fail, they either mess up all following tests or destabilize the cluster in ways we may not predict.

We have no rush to get this PR merged and from my point of view these observations are worth to be discussed like @xpivarc proposed. What would be a good way of shifting this discussion away from the PR to a wider forum?

I will be drafting a proposal for the wider kubevirt community to move these kind of destructive and edge case tests to their own separate test lane and out of the gating lanes. We are currently testing everything in the gating lanes including severe edge cases which does not make sense and makes CI very costly.

We will look at how to separate out these tests and where we want to run them.

fossedihelm · 2024-01-30T08:00:44Z

tests/vm_test.go

@@ -1969,12 +1969,25 @@ status:

 			By("Blocking virt-handler from reconciling the VMI")
 			libpod.AddKubernetesApiBlackhole(getHandlerNodePod(virtClient, nodeName), componentName)
-			Eventually(getHandlerNodePod(virtClient, nodeName).Items[0], 120*time.Second, time.Second, HaveConditionFalse(k8sv1.PodReady))


How about?

Eventually(func(g Gomega) { g.Expect(getHandlerNodePod(virtClient, nodeName).Items[0]).To(HaveConditionFalse(k8sv1.PodReady)) }, 120*time.Second, time.Second).Should(Succeed()) DeferCleanup(func() { libpod.DeleteKubernetesApiBlackhole(getHandlerNodePod(virtClient, nodeName), componentName) Eventually(func(g Gomega) { g.Expect(getHandlerNodePod(virtClient, nodeName).Items[0]).To(HaveConditionTrue(k8sv1.PodReady)) }, 120*time.Second, time.Second).Should(Succeed()) })

The issue with DeferCleanup is that it is executed after the resetToDefaultConfig() inside the global AfterEach. So when the AfterEach tries to reset kubevirt, the virt-handler is offline (unable to communicate with the kubernetes API). That creates this error: "resource & config versions (5548 and 4736 respectively) are not as expected. component: \"virt-handler\", pod: \"virt-handler-zdv7f\" " .

I like the Eventually proposal, looks elegant. Also implemented in the blackhole deleting check.

Why did we revert the defer or JustAfterEach?

I don't get it.
The defer is something that we can avoid as solution to cleanup. The JustAfterEach is generally used for different scopes.
Here, the problem was the DeferCleanup. After some searches I found this onsi/ginkgo#1284 (comment)

In reality Ginkgo runs the After* family followed by the Defer* family.

which explain the source of the issue.
(We should check our other DeferCleanup usages IMHO).
Can you explain your doubts?
Thanks

@jcanocan also observed that an AfterEach is only run after the global AfterEach afaik.

Thanks @fossedihelm for this nice piece of information. This explains all the issues faced.

As far as I was able to test, the nearest AfterEach (the one inside the Context) is always executed before the global AfterEach. However, we need a way to wait until the handler and kubevirt versions are in sync. That's why I've observed in the past the error mentioned in the description. Sorry for the confusion.

fossedihelm · 2024-01-30T13:59:21Z

tests/vm_test.go

@@ -1957,24 +1957,37 @@ status:

 	Context("[Serial] when node becomes unhealthy", Serial, func() {
 		const componentName = "virt-handler"
+		var nodeName string
+
+		JustAfterEach(func() {


AfterEach is enough here. Inner AfterEach are executed before the outer one

The linter enforces the usage of `Should()` statements when a `Eventually` check is used. Also, `DeferCleanup` has been dropped in favor of `AfterEach`. The [`resetToDefaultConfig()` ](https://github.com/kubevirt/kubevirt/blob/cb1b6e53540189d6664c4a8c126ab6e0a84ff8c4/tests/utils.go#L1842) is called before the test `DeferCleanup`, creating the following error: "resource & config versions (5548 and 4736 respectively) are not as expected. component: \"virt-handler\", pod: \"virt-handler-zdv7f\" " This is because the `virt-handler` will not be ready (intentionally for the purposes of the test), and the `resetToDefaultConfig()` will force the `virt-handler` to reconcile, which will fail, but the `virt-handler` `resourceVersion` will be updated. Therefore, the Kubevirt object will be out of sync. Signed-off-by: Javier Cano Cano <jcanocan@redhat.com>

jcanocan · 2024-01-30T16:05:48Z

Dropped the configuration update in the AfterEach to check if the WaitForConfigToBePropagatedToComponent() is enough to sync Kubevirt and virt-handler.

fossedihelm · 2024-01-30T16:39:27Z

/lgtm
Thanks!
@xpivarc would you like to take a further look before unhold?

kubevirt-commenter-bot · 2024-01-30T16:39:32Z

Required labels detected, running phase 2 presubmits:
/test pull-kubevirt-e2e-kind-1.27-sriov
/test pull-kubevirt-e2e-k8s-1.29-ipv6-sig-network
/test pull-kubevirt-e2e-k8s-1.27-sig-network
/test pull-kubevirt-e2e-k8s-1.27-sig-storage
/test pull-kubevirt-e2e-k8s-1.27-sig-compute
/test pull-kubevirt-e2e-k8s-1.27-sig-operator
/test pull-kubevirt-e2e-k8s-1.28-sig-network
/test pull-kubevirt-e2e-k8s-1.28-sig-storage
/test pull-kubevirt-e2e-k8s-1.28-sig-compute
/test pull-kubevirt-e2e-k8s-1.28-sig-operator

xpivarc · 2024-01-30T16:47:56Z

tests/vm_test.go

+		AfterEach(func() {
+			libpod.DeleteKubernetesApiBlackhole(getHandlerNodePod(virtClient, nodeName), componentName)
+			Eventually(func(g Gomega) {
+				g.Expect(getHandlerNodePod(virtClient, nodeName).Items[0]).To(HaveConditionTrue(k8sv1.PodReady))
+			}, 120*time.Second, time.Second).Should(Succeed())
+
+			tests.WaitForConfigToBePropagatedToComponent("kubevirt.io=virt-handler", util.GetCurrentKv(virtClient).ResourceVersion,
+				tests.ExpectResourceVersionToBeLessEqualThanConfigVersion, 120*time.Second)
+		})


This is not flaky?

I'm trying to find out if this may lead to flaky. The purpose is to wait until configuration versions are in sync. I ran out of ideas in this regard. So I think we should rerun a couple of times the pull-kubevirt-check-tests-for-flakes to find it out. Sorry for the brute force approach 😞

xpivarc · 2024-01-30T16:48:22Z

tests/vm_test.go

@@ -1969,12 +1969,25 @@ status:

 			By("Blocking virt-handler from reconciling the VMI")
 			libpod.AddKubernetesApiBlackhole(getHandlerNodePod(virtClient, nodeName), componentName)
-			Eventually(getHandlerNodePod(virtClient, nodeName).Items[0], 120*time.Second, time.Second, HaveConditionFalse(k8sv1.PodReady))


Why did we revert the defer or JustAfterEach?

xpivarc · 2024-01-31T09:10:43Z

/retest pull-kubevirt-check-tests-for-flakes

kubevirt-bot · 2024-01-31T09:10:47Z

@xpivarc: The /retest command does not accept any targets.
The following commands are available to trigger required jobs:

/test pull-kubevirt-apidocs
/test pull-kubevirt-build
/test pull-kubevirt-build-arm64
/test pull-kubevirt-check-unassigned-tests
/test pull-kubevirt-client-python
/test pull-kubevirt-e2e-k8s-1.27-sig-compute
/test pull-kubevirt-e2e-k8s-1.27-sig-network
/test pull-kubevirt-e2e-k8s-1.27-sig-operator
/test pull-kubevirt-e2e-k8s-1.27-sig-performance
/test pull-kubevirt-e2e-k8s-1.27-sig-storage
/test pull-kubevirt-e2e-k8s-1.28-sig-compute
/test pull-kubevirt-e2e-k8s-1.28-sig-network
/test pull-kubevirt-e2e-k8s-1.28-sig-operator
/test pull-kubevirt-e2e-k8s-1.28-sig-storage
/test pull-kubevirt-e2e-k8s-1.29-ipv6-sig-network
/test pull-kubevirt-e2e-k8s-1.29-sig-compute
/test pull-kubevirt-e2e-k8s-1.29-sig-compute-migrations
/test pull-kubevirt-e2e-k8s-1.29-sig-network
/test pull-kubevirt-e2e-k8s-1.29-sig-operator
/test pull-kubevirt-e2e-k8s-1.29-sig-storage
/test pull-kubevirt-e2e-kind-1.27-sriov
/test pull-kubevirt-e2e-kind-1.27-vgpu
/test pull-kubevirt-e2e-windows2016
/test pull-kubevirt-fossa
/test pull-kubevirt-generate
/test pull-kubevirt-manifests
/test pull-kubevirt-prom-rules-verify
/test pull-kubevirt-unit-test
/test pull-kubevirt-verify-go-mod

The following commands are available to trigger optional jobs:

/test build-kubevirt-builder
/test pull-kubevirt-build-s390x
/test pull-kubevirt-check-tests-for-flakes
/test pull-kubevirt-code-lint
/test pull-kubevirt-conformance-arm64
/test pull-kubevirt-e2e-arm64
/test pull-kubevirt-e2e-k8s-1.25-fips-sig-compute
/test pull-kubevirt-e2e-k8s-1.29-sig-compute-realtime
/test pull-kubevirt-e2e-k8s-1.29-sig-compute-root
/test pull-kubevirt-e2e-k8s-1.29-sig-monitoring
/test pull-kubevirt-e2e-k8s-1.29-sig-network-multus-v4
/test pull-kubevirt-e2e-k8s-1.29-sig-storage-root
/test pull-kubevirt-e2e-k8s-1.29-single-node
/test pull-kubevirt-e2e-k8s-1.29-swap-enabled
/test pull-kubevirt-gosec
/test pull-kubevirt-goveralls
/test pull-kubevirt-metrics-lint
/test pull-kubevirt-unit-test-arm64
/test pull-kubevirt-verify-rpms

Use /test all to run the following jobs that were automatically triggered:

pull-kubevirt-apidocs
pull-kubevirt-build
pull-kubevirt-build-arm64
pull-kubevirt-check-tests-for-flakes
pull-kubevirt-check-unassigned-tests
pull-kubevirt-client-python
pull-kubevirt-code-lint
pull-kubevirt-conformance-arm64
pull-kubevirt-e2e-arm64
pull-kubevirt-e2e-k8s-1.29-sig-compute
pull-kubevirt-e2e-k8s-1.29-sig-compute-migrations
pull-kubevirt-e2e-k8s-1.29-sig-network
pull-kubevirt-e2e-k8s-1.29-sig-operator
pull-kubevirt-e2e-k8s-1.29-sig-storage
pull-kubevirt-e2e-kind-1.27-vgpu
pull-kubevirt-e2e-windows2016
pull-kubevirt-fossa
pull-kubevirt-generate
pull-kubevirt-goveralls
pull-kubevirt-manifests
pull-kubevirt-prom-rules-verify
pull-kubevirt-unit-test
pull-kubevirt-unit-test-arm64
pull-kubevirt-verify-go-mod

In response to this:

/retest pull-kubevirt-check-tests-for-flakes

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

xpivarc · 2024-01-31T09:10:58Z

/test pull-kubevirt-check-tests-for-flakes

jcanocan · 2024-01-31T12:29:09Z

/test pull-kubevirt-check-tests-for-flakes

jcanocan · 2024-01-31T15:55:39Z

/test pull-kubevirt-check-tests-for-flakes

jcanocan · 2024-02-01T10:08:07Z

/retest-required

jcanocan · 2024-02-01T13:55:28Z

/test pull-kubevirt-check-tests-for-flakes

jcanocan · 2024-02-01T15:30:56Z

@xpivarc flakes failed, but no because this test. Please, retest it when you have taken a look.

xpivarc · 2024-02-01T15:36:19Z

/hold cancel
@fossedihelm

fossedihelm

Thank you!

kubevirt-commenter-bot · 2024-02-01T15:40:05Z

Required labels detected, running phase 2 presubmits:
/test pull-kubevirt-e2e-windows2016
/test pull-kubevirt-e2e-kind-1.27-vgpu
/test pull-kubevirt-e2e-kind-1.27-sriov
/test pull-kubevirt-e2e-k8s-1.29-ipv6-sig-network
/test pull-kubevirt-e2e-k8s-1.27-sig-network
/test pull-kubevirt-e2e-k8s-1.27-sig-storage
/test pull-kubevirt-e2e-k8s-1.27-sig-compute
/test pull-kubevirt-e2e-k8s-1.27-sig-operator
/test pull-kubevirt-e2e-k8s-1.28-sig-network
/test pull-kubevirt-e2e-k8s-1.28-sig-storage
/test pull-kubevirt-e2e-k8s-1.28-sig-compute
/test pull-kubevirt-e2e-k8s-1.28-sig-operator

kubevirt-commenter-bot · 2024-02-02T04:00:13Z

/retest-required
This bot automatically retries required jobs that failed/flaked on approved PRs.
Silence the bot with an /lgtm cancel or /hold comment for consistent failures.

kubevirt-bot · 2024-02-02T16:01:58Z

@jcanocan: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
pull-kubevirt-check-tests-for-flakes	`e43402d`	link	false	`/test pull-kubevirt-check-tests-for-flakes`

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

kubevirt-commenter-bot · 2024-02-02T19:02:37Z

/retest-required
This bot automatically retries required jobs that failed/flaked on approved PRs.
Silence the bot with an /lgtm cancel or /hold comment for consistent failures.

kubevirt-commenter-bot · 2024-02-02T22:01:52Z

/retest-required
This bot automatically retries required jobs that failed/flaked on approved PRs.
Silence the bot with an /lgtm cancel or /hold comment for consistent failures.

kubevirt-bot added release-note-none Denotes a PR that doesn't merit a release note. dco-signoff: yes Indicates the PR's author has DCO signed all their commits. size/XS labels Jan 29, 2024

kubevirt-bot requested review from EdDev and kbidarkar January 29, 2024 12:10

jcanocan mentioned this pull request Jan 29, 2024

[release-1.1] fix: Reduce VM recovery times #11100

Merged

8 tasks

xpivarc approved these changes Jan 29, 2024

View reviewed changes

kubevirt-bot assigned xpivarc Jan 29, 2024

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

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

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

jcanocan force-pushed the fix-eventually branch from 690e4e8 to ab9a255 Compare January 29, 2024 14:32

kubevirt-bot added size/S and removed lgtm Indicates that a PR is ready to be merged. size/XS labels Jan 29, 2024

jcanocan force-pushed the fix-eventually branch 2 times, most recently from 12ec7ae to 788b5b6 Compare January 29, 2024 16:57

jcanocan changed the title ~~fix: Eventually() missing Should() statement~~ fix: Eventually() missing Should() statement and sync error Jan 29, 2024

jcanocan force-pushed the fix-eventually branch from 788b5b6 to 29018dd Compare January 29, 2024 17:52

xpivarc reviewed Jan 30, 2024

View reviewed changes

xpivarc mentioned this pull request Jan 30, 2024

Enable ginkgolinter in make lint #11107

Merged

EdDev reviewed Jan 30, 2024

View reviewed changes

fossedihelm reviewed Jan 30, 2024

View reviewed changes

jcanocan force-pushed the fix-eventually branch from 29018dd to beea79a Compare January 30, 2024 09:13

fossedihelm reviewed Jan 30, 2024

View reviewed changes

jcanocan force-pushed the fix-eventually branch from beea79a to e43402d Compare January 30, 2024 16:04

kubevirt-bot assigned fossedihelm Jan 30, 2024

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

xpivarc requested changes Jan 30, 2024

View reviewed changes

kubevirt-bot removed the lgtm Indicates that a PR is ready to be merged. label Jan 30, 2024

kubevirt-bot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Feb 1, 2024

fossedihelm approved these changes Feb 1, 2024

View reviewed changes

kubevirt-bot added the lgtm Indicates that a PR is ready to be merged. label Feb 1, 2024

kubevirt-bot merged commit 2dab5d4 into kubevirt:main Feb 3, 2024
35 of 36 checks passed

	By("changing a setting and ensuring that the config update watcher eventually resumes and picks it up")
	migrationBandwidth := resource.MustParse("1Mi")
	kv := util.GetCurrentKv(virtCli)
	kv.Spec.Configuration.MigrationConfiguration = &k6sv1.MigrationConfiguration{
	BandwidthPerMigration: &migrationBandwidth,
	}
	kv = testsuite.UpdateKubeVirtConfigValue(kv.Spec.Configuration)
	tests.WaitForConfigToBePropagatedToComponent("kubevirt.io=virt-handler", kv.ResourceVersion, tests.ExpectResourceVersionToBeLessEqualThanConfigVersion, 60*time.Second)
	})

fix: Eventually() missing Should() statement and sync error #11101

fix: Eventually() missing Should() statement and sync error #11101

Conversation

jcanocan commented Jan 29, 2024 • edited

xpivarc left a comment

Choose a reason for hiding this comment

kubevirt-bot commented Jan 29, 2024

kubevirt-commenter-bot commented Jan 29, 2024

xpivarc commented Jan 29, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

EdDev Jan 30, 2024 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

EdDev Jan 30, 2024 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jcanocan commented Jan 30, 2024

fossedihelm commented Jan 30, 2024

kubevirt-commenter-bot commented Jan 30, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

xpivarc commented Jan 31, 2024

kubevirt-bot commented Jan 31, 2024

xpivarc commented Jan 31, 2024

jcanocan commented Jan 31, 2024

jcanocan commented Jan 31, 2024

jcanocan commented Feb 1, 2024

jcanocan commented Feb 1, 2024

jcanocan commented Feb 1, 2024

xpivarc commented Feb 1, 2024

fossedihelm left a comment

Choose a reason for hiding this comment

kubevirt-commenter-bot commented Feb 1, 2024

kubevirt-commenter-bot commented Feb 2, 2024

kubevirt-bot commented Feb 2, 2024 • edited

kubevirt-commenter-bot commented Feb 2, 2024

kubevirt-commenter-bot commented Feb 2, 2024

fix: `Eventually()` missing `Should()` statement and sync error #11101

fix: `Eventually()` missing `Should()` statement and sync error #11101

jcanocan commented Jan 29, 2024 •

edited

EdDev Jan 30, 2024 •

edited

EdDev Jan 30, 2024 •

edited

kubevirt-bot commented Feb 2, 2024 •

edited