-
Notifications
You must be signed in to change notification settings - Fork 431
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
wait for provisioning state in AKS e2e tests #4255
Conversation
@@ -65,6 +66,7 @@ func AKSUpgradeSpec(ctx context.Context, inputGetter func() AKSUpgradeSpecInput) | |||
Eventually(func(g Gomega) { | |||
resp, err := managedClustersClient.Get(ctx, infraControlPlane.Spec.ResourceGroupName, infraControlPlane.Name, nil) | |||
g.Expect(err).NotTo(HaveOccurred()) | |||
g.Expect(resp.Properties.ProvisioningState).To(Equal(ptr.To("Succeeded"))) |
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.
FYI @willie-yao I think this overlaps with a change you added to #4155.
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.
Looks like my change is accomplishing the same thing although the provisioning state is coming from the managed cluster itself rather than the response properties. Is the behavior any different?
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #4255 +/- ##
=======================================
Coverage 58.16% 58.16%
=======================================
Files 187 187
Lines 19351 19351
=======================================
Hits 11256 11256
Misses 7457 7457
Partials 638 638 ☔ View full report in Codecov by Sentry. |
/test pull-cluster-api-provider-azure-conformance-custom-builds |
/test pull-cluster-api-provider-azure-e2e-aks Flake hunting 🔎 |
/test pull-cluster-api-provider-azure-e2e-aks |
1 similar comment
/test pull-cluster-api-provider-azure-e2e-aks |
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.
/lgtm
LGTM label has been added. Git tree hash: 59448553444bc6247ef8041b3ef87fcc40eab376
|
/lgtm |
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.
/lgtm
/approve
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: mboersma 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 |
/cherry-pick release-1.11 |
@mboersma: once the present PR merges, I will cherry-pick it on top of release-1.11 in a new PR and assign it to you. In 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/test-infra repository. |
@mboersma: #4255 failed to apply on top of branch "release-1.11":
In 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/test-infra repository. |
@mboersma: #4255 failed to apply on top of branch "release-1.10":
In 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/test-infra repository. |
What type of PR is this?
/kind flake
What this PR does / why we need it:
Many of the e2e test specs for managed clusters make some update to a CAPZ resource and then wait for that change to be reflected in Azure. Until now, this wait hasn't taken into account the
provisioningState
of the resource in Azure, which changes from "Updating" to "Succeeded" when the operation is done. Anecdotally, I tend to observe updates in the Azure API to apply a noticeable amount of time before operations finish. I have a hypothesis that the current behavior is causing the tests to progress too quickly and cause issues like #3955 and #4069 (comment).This PR inserts checks that the provisioning state of the AKS resources is Succeeded alongside the existing checks that the other relevant API fields have been updated to ensure the cluster is in a successful state and not actively being updated before moving on.
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 #3955
Special notes for your reviewer:
TODOs:
Release note: