Repository navigation
test(mesh): wait for what a step needs before the regrade scenario takes it - #141
Merged
Merged
Conversation
…kes it The scenario stopped the watcher on the stepped-up server as soon as its level read full. The service records the level before it makes the Node schedulable again and gives the Lease back, so the stop could land between the two and leave the Lease held, and the next step by hand was refused as held by the first server. The scenario now waits for the watcher to log the end of its step and for the Lease to be free. After the stepped-down server's container was recreated, the step up by hand ran as soon as the level file read etcd-only. The kubectl the service uses is the one in that container, with the kubeconfig k3s writes some seconds after it starts, so the step was refused because the nodes could not be listed. The scenario now waits until the service can list them, which is what the step reads first.
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
This security review couldn’t start because the paying account has exhausted its Codex allowance and has insufficient available credits. The payer can check their balance and add credits in the Codex usage dashboard, then try again. If you do not manage the paying account, contact this repository's admins. |
|
🎉 This PR is included in version 2.7.10 🎉 The release is available on:
Your semantic-release bot 📦🚀 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
The regrade scenario of the mesh integration test fails on main, and not always on the same line. Both causes are races in the test's own timing, so a run passes or fails on how quickly k3s and the watcher happen to move.
After the watcher steps node 2 back up, the test stopped the watcher as soon as the level read full. The service records the level before it uncordons the Node and gives the Lease back, so the kill could land in between and leave the Lease held by node 2, and the later step down by hand on node 3 was refused with "the lease is held by grtest-node2". The test now waits for the watcher to log the end of its step and for the Lease to be free before stopping it.
After node 3's container is recreated at etcd-only, the test ran the step up by hand as soon as the level file read etcd-only. The service uses the kubectl in that container, with the kubeconfig k3s writes a few seconds after it starts, so the step was refused with "the etcd-voting nodes cannot be listed". The test now waits until the service can list the nodes, which is the first thing a step reads.
The role and scripts behave as designed: a step refuses safely in both cases. I reproduced the second failure locally on the first run of the unchanged scenario, and the scenario passes locally with the change.