🌱Add test for baremetalhost controller updateEventHandler#1881
Conversation
|
Hi @troy0820. Thanks for your PR. I'm waiting for a metal3-io member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions 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-sigs/prow repository. |
8ae68ff to
1e33d18
Compare
7fe7bfe to
1e5696c
Compare
|
/ok-to-test |
|
/test metal3-bmo-e2e-test |
|
@troy0820: The specified target(s) for
The following commands are available to trigger optional jobs:
Use
DetailsIn response to this:
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-sigs/prow repository. |
|
/retest Not sure why the tests are not re-running, but I can push an empty commit. |
|
Thanks for the contribution! Let's squash those commits up. Let's get some eyes on this. |
15cc788 to
662161e
Compare
|
I am trying to understand this patch a bit, the original issue pointed by @s3rj1k was an edge case where code updated the status/BMH object even when there was no actual change in status, but it seems this patch is ignoring updating the object even when theres is any update on the status? Am I understanding it correctly? |
|
/cc @zaneb |
The object is updated but it doesn’t requeue the object in the event that the status last changed gets updated during a saveStatus. This was supposed to be handled by the predicate generation changed but seems to slip through. |
zaneb
left a comment
There was a problem hiding this comment.
I'm not sure this has any effect.
It's probably safe as long as we always remember to return Requeue:true whenever we need to requeue.
I think we do, but I also thought that we avoid writing unchanged statuses (as Dmitry pointed out), yet according the the bug report we do not. (OTOH, I'm not sure whether to believe this, because when asked where this happens the response was "check the code", and yet upon checking the code it's clearly fine.)
|
/cc @andfasano, who appears to me to have already solved this exact issue in 2020 with #747. |
|
Running the test that I added as part of this change works without the patch included. So I can dismiss this change and leave the test but we probably should close the issue if it is fixed. |
662161e to
611dffd
Compare
Signed-off-by: Troy Connor <troy0820@users.noreply.github.com>
611dffd to
2373f90
Compare
|
Reading over the bug report, the complaint was that we were doing no-op updates in the first place (although there is no evidence of this yet), thus causing extra work for other controllers that were watching the BMH. I'm fine with adding a test though. We could even test that all updates to the Status are ignored. |
|
/cc @kashifest |
|
/cc @kashifest @zaneb @dtantsur @elfosardo |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: kashifest The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
What this PR does / why we need it:
When using this method, thesaveHostStatuswill requeue the object and create more reconciles for the object when the only thing that has changed is the lastupdated field in the status. This leads to multiple reconciles because this happens during each run through the reconciler.This adds a test to the baremetalhost controller to validate that the saveHostStatus will not requeue the object and create more reconciles when lastUpdated is updated.
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 #1253