Option for postponed execution of "on_activate()" code for ShellDriver and SSHDriver

[nmhaker]

Dear, I will try to explain the issue we are having in hope that there is already some solution that you can give us to the problem we have, that we are not aware of, so that we don't need to change labgrid native code.

Our understanding is as follows:

ShellDriver and SSHDriver on_activate() method is being executed automatically via labgrid lifecycle once Environment.yaml is parsed in which these drivers are used.
However code inside on_activate() is unconditionally trying to, in case of ShellDriver get to the prompt, while in case of SSHDriver, establish functional ssh connection.
Now this is a problem for our case where we use Labgrid, extended on our side, to do low level flashing of devices.
As when trying to flash device you can have device which doesn't have working image:

• Device has no image at all until flashed
  • not possible to get shell prompt to this device -> ShellDriver initialization fails
  • not possible to get ssh connection to this device -> SSHDriver initialization fails
• Flashing failed so device left in bricked image mode
  • same...
  • same...
• Some other reason that left device into non connectable state in some mode, where pure serial (console) connection only maybe can be used.
  • same...
  • same...

However since this happens during initialization of labgrid and parsing of Environment.yaml we can't react and prevent this so labgrid times out, crashes.

In our case it would be ok if labgrid initialized successfully, without trying to establish shell and ssh connection, but initializing drivers nevertheless.
And later when we use them we have opportunity to activate them in defined way.

Our solution was to change labgrid drivers and add parameter to ShellDriver and SSHDriver and use it in in a fixed way set in our environment.yaml so that we skip this unnecessary initial connections. However that has implication that, as long as you use that same environment.yaml, shell and ssh commands will not work from labgrid-client as initial stuff is skipped that should happen in this case, but not for our command. So basically we plan to mitigate this by using separate environment.yaml files...

Is there any better solution than this ?
Could it be that nobody up until know had this use case, or lets say, expected to use labgrid on device that doesn't have "functionally running linux" ?

I imagine that there are probably other drivers having the same issue/use-case that I didn't mention here.

[Bastian-Krause]

That's not how labgrid works. Only if you activate a driver, its on_activate() method is called.

See: https://labgrid.readthedocs.io/en/latest/overview.html#binding-and-activation
https://labgrid.readthedocs.io/en/latest/usage.html#driver-activation

Please tell us how you exactly use labgrid.

[nmhaker]

Ok, based on your answer, I believe you also meant that "Drivers in environment.yaml are not automatically activated" ?
Based on this, I went and read whole codebase again and I think I understand better now, so activation is not happening at this point, however culprit seems to be in next step...:

• In our environment.yaml we use our own custom driver that I believe is implemented correctly.
• There we also define and use ShellDriver and SSHDriver
• However we are BINDING ShellDriver and SSHDriver to it...
• And based on the explanation in the link you provided to me:

Seems that whatever you put into "binding: []" of given driver is also activated when you activate that driver. And I believe this is our issue... we are binding ShellDriver and SSHDriver but we don't want to activate them when we activate our driver :) ... Basically we either must use our driver "un-activated" to prevent this if that is possible and ok, or not bind this 2 drivers to our driver, but fetch them via code globally from yaml and activate manually, which removes clarity from our custom driver... Hmm... And regarding the code that does this, I guess that is this piece in target.py in `activate()` method ? : I need to try out and check this tomorrow to not put them in binding and see behavior, but is my understanding now correct ?

[Bastian-Krause]

Ok, based on your answer, I believe you also meant that "Drivers in environment.yaml are not automatically activated" ?

Yes.

Seems that whatever you put into "binding: []" of given driver is also activated when you activate that driver. And I believe this is our issue... we are binding ShellDriver and SSHDriver but we don't want to activate them when we activate our driver :) ...

Higher level driver binding on top of lower level drivers is one of the foundational concepts in labgrid. Please don't try to work around that.

Basically we either must use our driver "un-activated" to prevent this if that is possible and ok, or not bind this 2 drivers to our driver, but fetch them via code globally from yaml and activate manually, which removes clarity from our custom driver... Hmm...

I think your custom driver's design might not be aligned with how labgrid works. It would be much easier if you could (at least on a high level) describe what your driver is meant to be doing (maybe you can even attach its source here?).

[nmhaker]

It would be much easier if you could (at least on a high level) describe what your driver is meant to be doing

Our use case is that we are executing tests on our boards in our custom infrastructure setup via CI/CD. In order for these tests to be run on our boards we have to be able to flash our boards.
And for this purpose we wrote our custom FlashingDriver that does all the magic of flashing different types of devices that we have with custom linux images.
Do you have some suggestion on how to properly approach our use case ?

(maybe you can even attach its source here?)

I am afraid I can't...

Basically today I confirmed on our side that before mentioned issue was the problem. We mitigated this issue by not activating our custom driver and we just use it without activating it. That way bindings are not immediately activated and wait our implementation inside our custom driver to do the job of activating bound drivers when they are needed and not prio to flashing process.

I think your custom driver's design might not be aligned with how labgrid works.

Having said things above, do you still think we are using it now in a wrong way, and if so, do you have some suggestion on how to do it better ?