ability to add custom resources/drivers to exporter/client

[sessl3r]

Hi all,
we have many labgrid-configured places in our lab (thanks for the great tool!). But sometimes we have the issue that we just for one project will need some slightly changed or a very custom driver (most of the time for power).

So it is clear we can write a custom driver and or resource and bundle it into the labgrid installation eventually even need to customize the exporter etc. But is there a way to do this more flexible? Eg. I have seen for remote.yaml there is a 'imports' key.

So what would be very good to have is a simple way to import a custom resource/driver into the labgrid-exporter for in our case power and then being able to control it from the labgrid-client. Is this possible? Any easy way you can think of to achieve such things? Would the client even need to know about the new driver?

Background is that we do not want to install new exporter/clients for every minimal change so we need some more generic way to handle it. Even if we could just call a external script to control power this would be good enough - but as far as I see the ExternalPowerDriver is not thought to be used as a exportable resource?

Regards,
Tobias

[Emantor]

Why not upstream the driver into labgrid? In the long run you will be able to ditch your locally built packages, but for development you need to create them either way. Adding importable classes to the labgrid-exporter is none trivial, since the client needs to know the new backend/driver anyway. At this point your than importing your files on the exporter and client, where you might as well replace the package instead of adding imports which may not be rolled out by configuration management.

The imports key is mostly there since the configuration parsing is the same. But the crucially missing part is the translation of local resources to remote resources, which may be easy for power but not for other resources.

[jluebbe]

The exporter has only very little knowledge of how to actually control the Resources (and it doesn't use any Drivers). It's focus is to provide the necessary information to the client to allow it to access the Resource. labgrid is designed this way as it allows the user the most flexibility, as they can do any necessary changes on the client side (including adding custom drivers). As the Driver executes in the client (as labgrid-client, pytest or just as library), it has to load the new Driver.

Whether you need to change the exporter depends on whether you have to add dynamic information (such as from udev). For example for NetworkPowerPorts, the exporter just passes the configuration to the coordinator unmodified, which allows setting a custom model property. Only the client has to know how to control that mode.

You could also just export custom fixed resource this way. When a Resource needs dynamic information, you need to have some code for translation in the exporter anyway.

For labgrid-client, you could use an environment yaml (via -c), which imports and instantiates your custom drivers. It will try to find a Driver with the correct Protocol before trying to instantiate one:

labgrid/labgrid/remote/client.py

Line 718 in bd0ede7

drv = target.get_driver("PowerProtocol")

[sessl3r]

So this if I understand correct sounds like a really good point. Will definitely try this soon.
And of course for more complex things either we would want to upstream the changes or at some point it would be an idea to have some kind of a generic resource for that where one can pass in some random string as the config which will be picked up by the custom driver.