Closed chaosi-zju closed 3 weeks ago
As for the purpose of verifying collected daemonSet status result, we just check status.currentNumberScheduled
maybe is enough? No need to cost time to wait every pod available.
As for the purpose of verifying collected daemonSet status result, we just check status.currentNumberScheduled maybe is enough? No need to cost time to wait every pod available.
It depends on what we want to test. If we are testing PP, I think we may need to wait for the workload to be ready. Otherwise, how can prove that this is not a problem with karmada?
Thank you for your opinion, and let me share my views:
I think we may need to wait for the workload to be ready. Otherwise, how can prove that this is not a problem with karmada?
Unlike CurrentNumberScheduled
, if the value of CurrentNumberScheduled
is not expected, it means that there must be a problem with the internal code of Karmada, and this test is valuable.
However, if the value of NumberReady
is not expected, it does not mean that there must be a problem with Karmada. It is very likely that the member cluster itself is the problem, so this test judgment is a bit speculative.
It depends on what we want to test.
I agree at this point. If you want to test a complete process for replicas propagation, replicas ready is a necessary condition.
But, as the test described, check whether the daemonSet status can be correctly collected
, yet NumberReady
not equal wantedReplicas
doesn't mean status collected failed. In the case of correct collection, inequality of NumberReady
and wantedReplicas
is allowed.
Besides, to some extent, fields such as currentNumberScheduled
is enough to verify that the whether status collection process success.
It depends on what we want to test. If we are testing PP, I think we may need to wait for the workload to be ready. Otherwise, how can prove that this is not a problem with karmada?
Hi @liangyuanpeng, in the current test, we are testing the aggregation of the workload resource status. We really should test that each field in the status is as expected. However, in the CI test environment, some workloads take a long time to pull images from member clusters and run successfully. Even more than the waiting time we set (a full 7 minutes), then we can not sacrifice a little bit of field detection, such as status replicas in ready (The logic for processing other fields is the same as that for processing this field. Therefore, this field can be considered as an equivalence test.), which will speed up our testing. How do you think?
hi @liangyuanpeng, any more opinions? Do you still insist on your previous views?
Thanks for your clear! it's make sense for me.
In favor of #5258 /assign @chaosi-zju
Which jobs are flaking:
https://github.com/karmada-io/karmada/actions/runs/10105441369/job/27946023672?pr=5255
Which test(s) are flaking:
Reason for failure:
the desired replicas of this daemonset is 3, actually the
currentNumberScheduled
is already 3, but 2 of them is unavailable, we mistakenly thought that the status collection failed.Anything else we need to know: