Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Configurable minimum worker nodecount #238
base: main
Are you sure you want to change the base?
Configurable minimum worker nodecount #238
Changes from all commits
c15b385
0c83839
6a76bd9
8e23239
b59a5e3
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi, any particular reason this test was removed ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it wasn't removed, I changed the text to what I believed possibly described it better. It's now in a separate context under the general context of "unhealthy node without api-server access" since both have similar requirements.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: this is duplicating above test
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, I included this because I need to ensure that the watchdog hasn't already been triggered. If the watchdog was already triggered, then the test would succeed as a false positive.
The other test may have tested it individually but that doesn't guarantee that by the time this test executes that it was in that state prior to execution. Test ordering could have a dramatic effect on this.
I can remove it to be sure if you really want that, I just wanted to avoid possible future false positives.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general the goal is that test ordering should not matter.
BeforeEach()
andAfterEach()
should bring the system into a known initial state for each test. I know though that this isn't easy always, and for these tests ordering did matter for sure. However, with the new reset of the watchdog that should be fixed? There also is a test thatReset()
works as expected 🤔But if test ordering still is an issue for this specific test, as a quick workaround
verifyWatchdogNotTriggered()
should be added after the reset call, not here, so it's bullet proof for all tests. I would revisit the reset() function in a follow up then.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: having this in a BeforeEach() would a bit cleaner
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks - I originally had it in a BeforeEach but due to other context I had thought that it was preferable by the team for it to be moved into the test - since it was only for this one individual test.
will move it back and submit after I'm able to get the tests running again.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's a bit matter of taste, whether it's worth for a single test to have a BeforeEach() block... I think it's cleaner, but again, a nit only and no blocker 🙂
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
please add a log statement before returning here, similar to the other returns