Assessment runner refactors #2123

We have some repeated patterns of looking through list of pods to find the one matching our expected name and then extracting some information from it. Rather than repeat this in multiple places we can refactor this pattern out in assessment_helpers and re-use it. Signed-off-by: stevenhorsman <steven@uk.ibm.com>

I used the `PodEventExtractor` method to compare against an expected error message, but didn't realise at the time that it just watched for the first warning message and returned that. We then use this output in `assessment_runner` to see if our expected error description is there. Note: As we use it in the `Assess` phase of testing and the pod should be in the expected state after the `WithSetup`, we should be able to replace the need for the watch and just get a list of the events - Rename to clarify that only warning (and error) events are considered and create a `ComparePodEventDescriptions` method in `assessment_helper` to help simplify the logic in `assessment_runner` and process all warning events looking for a description match, not just the first match. If no error was expected then mark the test as failing. - In some of the tests that expect failure events, as we are no longer watching for the first error, we should wait for pod to have gone into failed state before processing the events, in others we add a retry to check for the message. Based on the above logic we can simplify the instance type testing Signed-off-by: stevenhorsman <steven@uk.ibm.com>

Refactor out the instance type check to the assessment_helper, to make the assessment_runner flow easier to read Signed-off-by: stevenhorsman <steven@uk.ibm.com>

Refactor out the logic that checks the alternativeImage is used to make the assessment_runner flow cleaner Signed-off-by: stevenhorsman <steven@uk.ibm.com>

- Refactor out the logic that checks if nydus snapshotter was used for image pull, to make the assessment_runner flow cleaner. - Refactor IsPulledWithNydusSnapshotter to use remove the duplicated code and re-use other helper functions Signed-off-by: stevenhorsman <steven@uk.ibm.com>

Create new methods for VerifyCaaPodLogContains and getCaaPod to avoid duplication and improve readability. Signed-off-by: stevenhorsman <steven@uk.ibm.com>

No tests are using the `WithFailReason` option, so remove the code to reduce clutter Signed-off-by: stevenhorsman <steven@uk.ibm.com>

The [Go Wiki]|(https://go.dev/wiki/TestComments) states > On a practical level, prefer calling t.Error over t.Fatal. > t.Fatal is usually only appropriate when some piece > of test setup fails, without which you cannot run the > test at all. - Update t.Fatal's in assess methods to t.Error's - Pass pointers to pods rather than the Pod, like the Kubernetes e2e pod base does Signed-off-by: stevenhorsman <steven@uk.ibm.com>

Refactor out the logic that checks if the image pull timing, to make the assessment_runner flow cleaner. Signed-off-by: stevenhorsman <steven@uk.ibm.com>

After confidential-containers#2121 the rust version is no longer needed Signed-off-by: stevenhorsman <steven@uk.ibm.com>

As Wainer pointed out in the review, if we ran the e2e tests on a cluster with multiple worker nodes, then our logic for only checking for a single CAA pod might fail, so add an additional nodeName filter, so get the CAA that is running on the same node as the pod. Signed-off-by: stevenhorsman <steven@uk.ibm.com>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Assessment runner refactors #2123

Assessment runner refactors #2123

Commits on Oct 29, 2024