add more to test suite #257
Comments
|
I'm supposed to work on some e2e testing after my other PRs are done, so count me in! :D |
|
@smarterclayton whats the best location to add operator level tests ? That require a cluster. |
|
See the e2e-aws-operator jobs in openshift/release. Basically have a binary / script in your repo, copy their pattern, then you get passed a kubeconfig and can run. |
Ref: openshift#257 Add a basic test file, targeting a test case for openshift@44d5c52 since it's easy. Next step is to try hooking this up to Prow. (I'm a bit undecided about bash as a framework; looks like other projects are using Go, but eh...if we decide to do something else we can easily exec it, and anyways this is just to get the ball rolling)
|
One thing related to #294 is that I think it would be an extremely useful pattern for us to support spinning up a "testnode" machine type that is marked tainted; we could then use it as a target for e.g. upgrade and other testing. |
Add a basic test suite, targeting a test case for openshift@44d5c52 This is inspired by the cluster-image-registry-operator tests: https://github.com/openshift/cluster-image-registry-operator/blob/e6c7544903d2826d171be45cdde5a83a58d97383/test/e2e/main_test.go Next step is to try hooking this up to Prow. Related: openshift#257 Replaces: openshift#298
Note I called this `-op` and not `-operator` as otherwise prowgen warned me about too long of a job name. See: openshift/machine-config-operator#298 openshift/machine-config-operator#257
cgwalters
changed the title
|
I'm just going to repurpose this issue now for "let's add more to the test suite" since it's not covering much at all. I think we can add a test case for e.g. "add a MC that adds a file to workers" easily now. It'd also be good to extend that and script a reconciliation failure ( Testing SSH key updates should be pretty straightforward I think. But most interesting (for me) is testing OS updates, to do that nicely a pattern like #257 (comment) would help. |
|
This issue is basically done, we can track anything else via PRs. |
It should be pretty easy to put together a quick test suite in e.g. bash that given a running cluster, tests at least a nondestructive scenario of creating a MC, waiting for it to roll out, running a quick daemonset that verifies the files exist, then e.g. deletes it and verifies the nodes are back as they were.
We may be able to enhance non-destructive testing by creating a separate machineset too and having MCs being more destructive just to those nodes (e.g. making them degraded etc.)
The text was updated successfully, but these errors were encountered: