-
Notifications
You must be signed in to change notification settings - Fork 599
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
Create paired upgrade tests #8158
Create paired upgrade tests #8158
Conversation
cd0052c
to
174bef9
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #8158 +/- ##
==========================================
- Coverage 67.71% 67.45% -0.26%
==========================================
Files 370 371 +1
Lines 17946 18039 +93
==========================================
+ Hits 12152 12169 +17
- Misses 5020 5091 +71
- Partials 774 779 +5 ☔ View full report in Codecov by Sentry. |
/test upgrade-tests |
Hmm, the eventing-webhook doesn't start after downgrade, I see these events:
|
/test upgrade-tests |
The failures are caused by ContainerSource being deployed which brings SinkBinding and the test scripts try to scale down to 0 and back to 3, see #8161 |
7297183
to
6e2d381
Compare
Added a workaround for #8161 which makes the tests pass. |
/assign |
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 seems like a huge upgrade on the existing upgrade tests. Maybe once we have this in eventing and are happy with the API we can also look into adding this into reconciler-test?
Hmm. Possibly we could add it to reconciler-test. We could make it more configurable, for example these EnvOpts could be held as a field in |
I did that and pushed another commit here. |
# Workaround for https://github.com/knative/eventing/issues/8161 | ||
kubectl label namespace "${SYSTEM_NAMESPACE}" bindings.knative.dev/exclude=true --overwrite |
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 have some tracker to remove this workaround and/or note that this should be cleaned up on #8161 ?
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.
I can add a note on #8161 as soon as this PR is merged. Doing it before it's merged seems too early as I can't properly reference this workaround.
restConfig, err := pkgtest.Flags.ClientConfig.GetRESTConfig() | ||
if err != nil { | ||
log.Fatal("Error building client config: ", err) | ||
} | ||
|
||
// Getting the rest config explicitly and passing it further will prevent re-initializing the flagset | ||
// in NewStandardGlobalEnvironment(). The upgrade tests use knative.dev/pkg/test which initializes the | ||
// flagset as well. | ||
global = environment.NewStandardGlobalEnvironment(func(cfg environment.Configuration) environment.Configuration { | ||
cfg.Config = restConfig | ||
return cfg | ||
}) |
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.
Maybe it is worth making rekt-based upgrade tests rather than adding these rekt tests into the existing upgrade tests? Sort of like #7626 (comment)
cc @pierDipi
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.
The existing upgrade tests are actually based on https://github.com/knative/pkg/tree/main/test/upgrade package. This package is used in nearly all Knative repos - Serving, Eventing, EKB, operator.
My changes bring a glue between these upgrade tests and REKT framework. It is still possible to use the existing upgrade test framework and re-use REKT features that are already defined elsewhere as building blocks. The only necessity is to split the feature into two smaller features (SetupF, VerifyF) so that the upgrade framework can run individual parts as needed.
Regarding #7626 (comment) , I can see that as a suggestion to use REKT-based tests instead of re-using custom legacy code that was implemented earlier. My PR does that - it allows re-using REKT-based tests (features), with minimal changes.
It would be possible to move the types from upgrade.go
(DurableFeature, FeatureWithUpgradeTests, etc.) to reconciler-test and be re-used in Eventing, EKB. Right now this code is here in Eventing.
I don't have ideas how to create specific "rekt-based upgrade tests" without re-implementing a lot of stuff from knative/pkg.
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
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: Cali0707, mgencur 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-required |
Related to knative-extensions/eventing-kafka-broker#4047
This brings the building blocks for creating paired upgrade tests in other repositories like eventing-kafka-broker.
Proposed Changes
DurableFeature
which holds two interconnected features: SetupF, VerifyF. This allows re-using existing Features created for reconciler-test framework, with slight modifications. The original feature should be split into two parts:NewFeatureSmoke
- this will create an object that will run same tests before upgrade, after upgrade, after downgrade. This will always include creating new resources (Setup), verifying resources (Assert), and deleting namespace (Teardown).NewFeatureOnlyUpgrade
- will create resources before upgrade, verify and tear down after upgrade, there's no operation after downgrade.NewFeatureOnlyDowngrade
- will create resources after upgrade, verify and tear down after downgrade, there's no operation at the beginning before upgrade.NewFeatureBothUpgradeDowngrade
- this will create resources before upgrade, verify them after upgrade, and verify and tear down after downgrade.FeatureGroupWithUpgradeTests
which just aggregates operations across a slice of features.Pre-review Checklist
Release Note
Docs