jluebbe
commented
4 years ago When using the remote access layer (lg-coordinator, lg-exporter), the places are expected to be relatively static (as they normally refer to real HW). Right now I don't see an obvious way how dynamic emulators should work in that architecture.
With the existing code, you could setup your Target in Python code and generate the right parameters for the QEMUDriver. It would only run locally, though.
If you have something else besides QEMU, you could implement a custom driver for your emulator and provide the same Protocols to the higher-level drivers (such as the ShellDriver). Registering additional drivers is an intended use-case.
Hi Guys,
I read about this project and it seems very promising. I read through the readthedocs documentation, but I found no use-case for emulators with a dynamic lifecycle.
Let say, you would like to run a custom-built emulator with custom parameters such as QEMU. The value for the parameters is only defined during runtime as a previous automation step creates them (freshly built image, maybe the QEMU was also just built from source). How this can be handled by labgrid? Please note, that the emulator also has resource dependencies such as CPU and memory, so it cannot be infinite. Is it possible to make an emulator pool machine, which is able to serve a statically known number of emulator 'seats' (based on the available CPU and memory)? If a client could request a 'seat' an after acquiring it, the client could set up and use an emulator via SSH (or maybe via docker) on that pool machine(s). Does this seem a viable solution supported by labgrid? Or what kind of structure would you suggest for this use-case? I am open to contributing bits and pieces to this project in order to support this use-case, but I am interested in your opinions first.