-
Notifications
You must be signed in to change notification settings - Fork 13
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
e2e: more robust wait for MCP updates #1091
Conversation
The `machineconfig.go` source file held code to work with kubeletconfig and machineconfigpool objects. To improve clarity: move the code pertaining to kuebeltconfig in the relevant file, and rename the current file to convey it's actually about `machineconfigpool`s trivial code movement without any intended change. Signed-off-by: Francesco Romani <[email protected]>
the canonical name for the generic context parameter is `ctx`, so renaming accordingly. No intended change in behavior. Signed-off-by: Francesco Romani <[email protected]>
the `mcpInfo` object has a field called `obj` which always hold a `MachineConfigPool` object. So let's rename it `mcpObj` for clarity. No intended changes in behavior. Signed-off-by: Francesco Romani <[email protected]>
Replace the expectation BeNumerically(">", 0) with Not(BeEmpty()) for a tiny (arguably very tiny) extra clarity Signed-off-by: Francesco Romani <[email protected]>
|
4e9b9c6
to
878df91
Compare
|
/retest-required |
1 similar comment
/retest-required |
/cc @shajmakh |
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.
Looking good, thanks!
small comments inside
All updates, including unpausing MCPs may fail, even more likely on CI, so wrap it with Eventually for extra robustness. Signed-off-by: Francesco Romani <[email protected]>
878df91
to
0c6d4b5
Compare
Something has changed in the test logic that causes HCP flow to ask for MCP from the API server which leads to the error above |
thanks, will check |
test/e2e/install/install_test.go
Outdated
@@ -326,13 +326,14 @@ var _ = Describe("[Install] durability", Serial, func() { | |||
// TODO change to an image which is test dedicated | |||
nroObjRedep.Spec.ExporterImage = e2eimages.RTETestImageCI | |||
|
|||
// need to get MCPs before the mutation |
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.
this is the culprit for the hypershift lane failure
instead of following suit the MCP status transition Updated->Updating->Updated, which is racy and relatively fragile, let's use a stronger condition: we care about waiting for MCP to be updated with the desired state. So: 1. we record the current MCP resourceversion 2. we ask for our desired state 3. we wait for the MCP desired state to be `updated` again *but with different resourceversion* this should allow us to capture the conditions which describe our desired state while waiting for a stable state in a more robust way. Signed-off-by: Francesco Romani <[email protected]>
0c6d4b5
to
82a797d
Compare
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ffromani, Tal-or 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:
Approvers can indicate their approval by writing |
instead of chasing the MCP status transition updated -> updating -> updated, which is fragile and hard to get right both in theory and in practice, let's try a different approach.
When we change a MCP status (e.g. sending a new MachineConfig and/or pausing/unpausing)
updated
again but withdifferent resourceversion
this should allow us to capture the conditions which describe our desired state while waiting for a stable state in a more robust way.
Add minorish cleanups along the way.