-
Notifications
You must be signed in to change notification settings - Fork 425
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
v1alpha4 -> v1beta1 clusterctl upgrade test #1810
v1alpha4 -> v1beta1 clusterctl upgrade test #1810
Conversation
@shysank: The label(s) 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. |
/test pull-cluster-api-provider-azure-capi-e2e |
go.mod
Outdated
sigs.k8s.io/cluster-api v1.0.0 | ||
sigs.k8s.io/cluster-api/test v1.0.0 | ||
sigs.k8s.io/controller-runtime v0.10.2 | ||
sigs.k8s.io/cluster-api v0.0.0-20211028170527-10d89ceca938 |
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.
/hold
until this is in a CAPI release
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.
backport pr kubernetes-sigs/cluster-api#5541
the pull CAPI job has gotten really long recently with all the new test specs + clusterctl upgrade. Wondering if we should breakout api upgrade into its own job so it runs in parallel, or if there is any way of increasing parallelism on the existing jobs. wdyt? |
We could make it parallel by using ginkgo's parallelism, |
I'm pretty sure we do use parallelism, if you look at a recent run eg. https://prow.k8s.io/view/gs/kubernetes-jenkins/pr-logs/pull/kubernetes-sigs_cluster-api-provider-azure/1810/pull-cluster-api-provider-azure-capi-e2e/1454146115451490304, the total duration was 2h48, with 14 tests that ran at around ~30 minutes each (rough average), if they were running serially that would have taken 7 hours. The fact that we're running them on 3 Ginkgo nodes makes sense since that's roughly 3x the actual duration. |
yeah just saw that :) updated my comment |
race condition :) let's try to bump the number of nodes and see if it does anything good/bad? we might be limited on the prow side of things |
e349d04
to
73c13e6
Compare
/test pull-cluster-api-provider-azure-capi-e2e |
KCP upgrade in HA cluster failed, unrelated to this pr, |
/hold cancel |
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
Test started yesterday at 9:35 PM passed after 2h31m1s.
did you get anywhere with #1816? 2.5 hours is really long for a PR test
I tried a bunch of things. There is some weird things happening with ginkgo nodes which I can't find the root cause yet. I'll keep trying whenever I get time, but meanwhile, wdyt think about splitting the jobs as you had suggested earlier? |
+1 to splitting the clusterctl upgrade tests into a separate job |
We could also remove the KCP upgrade specs from the CAPI job and run them as part of k8s upgrade jobs once #1735 merges, see kubernetes-sigs/cluster-api#4896 (comment) |
test/e2e/capi_test.go
Outdated
@@ -257,5 +258,54 @@ var _ = Describe("Running the Cluster API E2E tests", func() { | |||
} | |||
}) | |||
}) | |||
|
|||
Context("upgrade from v1alpha4 to v1beta1, and scale workload clusters created in v1alpha4", func() { |
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.
can we add a tag to the context so it's easier to filter these out as part of #1869? Something like [API-Version-Upgrade]
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.
same for the other clusterctl upgrade spec that's already merged
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.
done, I've created a context API Version Upgrade
that embeds the 2 upgrade tests. Is that okay? Happy to switch it to the way you've suggested if that's the convention.
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.
Yeah that should work
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.
are you going to open a PR to add it to Ginkgo skip and add a separate job?
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.
ptal at kubernetes/test-infra#24392 whenever you get a chance
/test pull-cluster-api-provider-azure-capi-e2e |
/test ls |
@CecileRobertMichon: The specified target(s) for
The following commands are available to trigger optional jobs:
Use
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. |
/test pull-cluster-api-provider-azure-apiversion-upgrade |
@shysank: The following test failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. 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. I understand the commands that are listed here. |
/lgtm KCP upgrade spec failed but the expected tests ran |
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: CecileRobertMichon 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 |
/retest |
@shysank now that this merged, can we add it to the other beta release branch and as a periodic job? |
do you mean backporting this pr to release-1.x, and add a job in |
we should add least run it periodically on the main branch, in Separately, we might also want to backport this to release-1.0 so we can add an apiversion test for both |
+1
yeah it should be possible to backport |
@shysank: new pull request created: #1878 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. |
ah deleted the comment by mistake :( the bot works though |
What type of PR is this?
/kind other
What this PR does / why we need it:
Adds v1alpha4 -> v1beta1 upgrade test
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 #1809
Special notes for your reviewer:
Please confirm that if this PR changes any image versions, then that's the sole change this PR makes.
TODOs:
Release note: