-
Notifications
You must be signed in to change notification settings - Fork 247
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
✨ Add e2e tests #1303
✨ Add e2e tests #1303
Conversation
Skipping CI for Draft Pull Request. |
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.
Just noting somethings.
454820d
to
bbdc6a7
Compare
bbdc6a7
to
95c4a5a
Compare
95c4a5a
to
e1da7a0
Compare
d2cf4ff
to
9e3c194
Compare
bddcc24
to
ab47a4b
Compare
Successful run: https://jenkins.nordix.org/job/metal3-bmo-e2e/22/ 🎉 |
/bmo-e2e-tests |
Failed |
/metal3_baremetal-operator_e2e_tests |
/metal3-bmo-e2e-tests |
4 similar comments
/metal3-bmo-e2e-tests |
/metal3-bmo-e2e-tests |
/metal3-bmo-e2e-tests |
/metal3-bmo-e2e-tests |
424386d
to
66435d8
Compare
/metal3-bmo-e2e-test-pull |
/metal3-bmo-e2e-test |
/test-ubuntu-integration-main |
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.
Two nits which you can feel free to ignore too.
This adds a test suite for e2e tests. So far there is only a few tests related to inspection, but it should be enough to validate the approach. My hope is that this framework will be flexible enough to allow tests both in CI, using VMs, and on actual hardware. The tests can be configured through a config file. They can run on an existing cluster or set up a temporary kind cluster automatically. Similarly, BMO, Ironic and Cert-manager can all be deployed or not depending on configuration. Logs are collected for BMO and Ironic when deployed automatically, even in existing clusters.
66435d8
to
d16fb45
Compare
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: kashifest 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 |
1 similar comment
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: kashifest 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 |
Formatted both docs @tuminoid 🙂 |
/metal3-bmo-e2e-test |
🙄 /metal3-bmo-e2e-test |
/metal3-bmo-e2e-test |
/test-ubuntu-integration-main |
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
Thanks for the massive contribution. This is a great step forward in untangling the testing setup we have today.
What this PR does / why we need it:
Adds e2e tests for BMO. This is not in any way ready to replace the existing tests we run with the full Metal3 stack, but eventually they may become enough to test at least BMO in an end to end fashion. So far there is just tests for registering -> inspecting -> available.
My hope is that the tests will prove flexible enough to be able to run also on real hardware, but for CI purposes we will use VMs.
Reviewer guide
Thanks for reviewing this (very large) PR! I hope the line count does not scare you away. About 50 % of it is anyway just
go.{mod|sum}
. To help with the review I want to explain a few things here.test
its own module to avoid any issues with "breaking APIs" when we change the tests. We should not give any promises about stability of the test module at this time.common.go
is just adapted code from the CAPI framework. Specifically everything about the e2e config is heavily inspired by CAPI.Then some answers to questions I expect to pop up:
Q: Why should we have a config file for e2e tests?
A: The idea is to be able to reuse these tests and then we need some flexibility that the config file provides. For example, it should be possible to specify the BMC details for a real server and run the tests against it.
Q: Why not take BMH manifests as input to the test instead of providing only BMC details?
A: This would take away too much control from the tests. We need to be able to create the BMH objects to fit the tests.
Q: Is the config file format set in stone?
A: Absolutely not! I expect that we will extend/modify it in the future as we add more tests.
Q: Why use
cmctl
?A: It is a convenient way of installing cert-manager and ensuring that it is working. Cert-manager can otherwise be a bit tricky because it is not enough to wait for the pods to be running. It also needs a little time to initialize and register the webhooks. I do not expect this is how we will install cert-manager in the long run though.
Future work
I expect that we will want to work with this in the future and add more tests, configure things differently, etc.
Here are some of my ideas for what we should add.
os.Exec
. We can write native go code to install cert-manager, BMO and Ironic instead of usingkubectl
andcmctl
.ci-e2e.sh
script as a go library. Instead of relying onvirsh
andvirt-install
to set up VMs and network, we could have a small go library to do the same. This would be extremely useful also for CAPM3.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 #