RFC: Extending inventory of "test: interactive" primitives, in particular for multinode sync
Let me start presenting this RFC with an example, building set of proposed features incrementally.
So, we have https://lite.validation.linaro.org/scheduler/job/774233.1, which is a part of multinode job, running a docker linux + frdm_k64f devices in a multinode configuration, both devices are handled via "test: interactive" tests.
Motivation for "delay"
For linux side, we have this command issued: https://lite.validation.linaro.org/scheduler/job/774234/multinode_definition#defline101 ,
- command: "sleep 12". It's there to wait while the frdm_k64f side boots. And we're lucky that we run on Linux, with POSIX shell, and can issue a sleep command on the test device. We should not rely on that, because the same facility may be needed for e.g. baremetal device (like frdm) which doesn't have any "shell". Hence, the proposal is to add another script primitive (beyond the existing
- delay: 12
Motivation for multinode sync primitives
But a case presented above is of course a workaround, having a static delay to wait for another side to finish initialization is not reliable. Instead, LAVA offers means of "multinode synchronization", to allow devices in multinode group to wait on each other. But multinode sync currently doesn't work for "test: interactive", and this is essentially an RFC on the best way to enable. How multinode sync works with classical, POSIX-bound jobs ("test: definitions") is: on DUT, a set of LAVA helper commands are installed (lava-send, lava-wait, etc.). These are run as part of test script, like any other command. They produce a line of output matching special pattern. This matching happens in dispatcher connection handler, which takes care to actually execute multinode API calls. This way doesn't work for "test: interactive" in the arbitrary case. Because again, very often there's no shell at all, and if there's, it's usually very limited, and can't do "arbitrary" things. That's the whole difference of "test: definitions" vs "test: interactive". With first way, we induce DUT to do "arbitrary" things (like executing arbitrary shell commands and producing arbitrary output on stdout), while in the latter case, the system largely runs in its own predefined way, so we mostly watch its output for interesting things, and only sometimes feed some (adhoc) input. Any "control flow" should be also done on the dispatcher side, that includes multinode synchronization too. So, with that motivation, further primitives to add to "test: interactive" - almost one-to-one matching standard multinode utils:
- lava-send: messageID (key=val)* - lava-wait: messageID # TODO: consider to capture param values - lava-wait-all: messageID [role]
The idea of this RFC is however to consider problem domain more thoroughly, and try to enumerate more definitely useful primitives to add to "interactive", instead of adding them one by one in more adhoc way. Considering problem in general would hopefully allow to come up with more consistent featureset and syntax.