OpTestFastReboot: PTY handling

[debmc]

Tweak the timing of pexpect buffer management and add
some debug logging to help aide problem determination
when pty buffering issues.

Signed-off-by: Deb McLemore [email protected]

[sammj]

@stewart-ibm can you run this against one of your fast-reboot victim machines? :)

[ghost]

Shouldn't these be set by the state machine doing the goto_state() processing?

Or, rather, I guess the question is "What am I missing here?"

[debmc]

set by the state machine

The cases observed were when a box was left with who-knows-what setting and then when the detection grabbed the box (so we just picked up the shell/OS) and later when we reboot we do not know how the box was setup which can lead to unexpected results.

[ghost]

Deb McLemore <[email protected]> writes:

debmc commented on this pull request. > self.cv_SYSTEM.goto_state(OpSystemState.OS) else: + self.cv_SYSTEM.sys_set_bootdev_setup() > set by the state machine The cases observed were when a box was left with who-knows-what setting and then when the detection grabbed the box (so we just picked up the shell/OS) and later when we reboot we do not know how the box was setup which can lead to unexpected results.

Hrm... is it due to where we do the set_bootdev() calls in the OpTestSystem state machine that perhaps we're missing them?

…

-- Stewart Smith OPAL Architect, IBM.

[debmc]

state machine

Observed a few failure scenarios when I was testing individual tests and causing failure mid-test (so state machine transitions same-state-to-same-state without power cycles), then I reviewed each testcase module to assure that if the test failed was the state of the system left consistently, i.e. if tests which manipulate the state machine outside the normal flow are the artifacts left behind consistent for the next test fixture is assured of a healthy environment.

For example, if someone manually set the bootdev=setup (so it would stop at Petitboot), but manually booted to the Host OS, then started an op-test testcase the goto would find the Host OS and NOT cycle through a reboot where the bootdev's are properly synchronized with the physical state of the machine. We cannot cover all cases, but when out-of-band manipulation of the state machine takes place its probably good practice to attempt to have things recoverable and not to leave things in a bad way. For independent test execution order, the next test fixture may also want to perform a sendline "reboot" and expect the Host OS to come up, etc.