Repository navigation
E2e test planning #69
Description
Let's discuss about the test planning. Currently, we only test the happy path for the reboot
Ideas about follow-up tests:
- Extend the test TestUpdateReboot by rolling back to the previous image
- Pause the rollout and check that the resuming continue correctly
- Try to upgrade to no-existing image, the node should go in degraded state and the rollout should be paused
- Shutdown (manually) a node after the reboot to simulate a faulty node, after the upgrade. It should be reported as degraded
- Try to kill the controller/daemon during a roll-out. They should recover and the rollout should progress and terminate successfully
- Testing the happy path with the digests (once supported)
- Upgrade to an image protected by a pull secret (once supported)
- Try to switch to a completely different image e.g fedora to centos stream
- Test upgrades for the operator
Activity
jlebon commentedon Jun 29, 2026
One general note: since each test spawns a separate worker node, which takes time, I would bundle these subtests into tests where it makes sense. E.g. error conditions/recovery tests could all be checked together in one test for example.
jlebon commentedon Jun 29, 2026
Is the more general thing we're testing here that the node degrades successfully if rebooting into an image which doesn't actually have e.g. the kubelet?
This relates to #14.
jlebon commentedon Jul 23, 2026
@ptalgulk01 Another useful test here is: you start a rollout for a certain image, and then change the target image during the rollout. We should still see all the nodes eventually converge to the updated target image (even if some might've already rebooted into the old one by then). This is important because it verifies that the state machines of the controller and daemon can't deadlock each other during corner cases.
ptalgulk01 commentedon Jul 27, 2026
thank you, I have added the test scenario here https://github.com/bootc-dev/bootc-operator/pull/115/changes#diff-f653b9b9559a51ff5f52f509882107638c85311fb6074afffc018e1b4ef9fbc0R404
cheesesashimi commentedon Sep 2, 2026
There could be a possible intersection between this and #108
e2e: add daemon-recovery, reboot-timeout, and operator-restart-resili…
e2e: add daemon-recovery, reboot-timeout, and operator-restart-resili…
e2e: add daemon-recovery, reboot-timeout, and operator-restart-resili…
e2e: add daemon-recovery, reboot-timeout, and operator-restart-resili…
alicefr commentedon Oct 20, 2026
@ptalgulk01 I think we can close this. A part from the test number 8, we have already include all of them. The eightth test I would say we skip it for now, since it requires some implementation in bink