Servient's runScript() lacks management funcionality (stop, monitor)

[miguelrk]

feat(core): add support for script runtime management functionality into Servient

Hello everyone! I realized the core/Servient runScript() and runPriviledgedScript() methods only allow running arbitrary code, without the ability to stop it. I have a use case where I need to execute scripts and have not only basic management like stop, restart, but also more advanced process monitoring capabilities (e.g. metrics, logs).

Digging into the documentation for the vm/vm2 libraries, I haven't found a way of doing so with such libraries. On the other hand, a process monitoring library like pm2 does allow not only running but also stopping processes as well as programatic access to monitoring information and metrics (which is in any case, a nice to have). It basically allows programatically embedding a process manager directly in code, spawning processes, keeping them alive even if the main script is exited.

Request:
Would it be possible to consider a process management library like pm2 rather than vm/vm2 for the runScript() and runPriviledgedScript() methods, and additionally add something like stopScript(), restartScript() and maybe e.g. getInfo() getActiveProcesses() among other useful features for monitoring the running scripts. This might be necesarry for production use cases where you cannot simply run and forget. I am not sure of the sandboxing capabilities offered by pm2 though.

Thanks!

[danielpeintner]

Note: we have been just recently switching to vm2 because of some shortcomings in vm.
@relu91 do you have an opinion?

[relu91]

tl;dr

It is a cool feature, but I think it is complex to implement and maintain. Moreover, you have alternative ways to achieve the same result.

longer answer

This issue came up a while ago also inside my research group. We posted a similar issue regarding the subject: #155. Implementing a stop function is not only an implementation detail but it has implications also at the architectural level. For example see the other issue that I posted: #w3c/wot-architecture#417. In particular, see my comment, where I explain the difference between a "Single Application" servient and a "Hypervisor" servient.

If we wanna have the stop feature, we should move to a "Hypervisor" servient whereas right now node-wot is more oriented to a "Single Application" servient. I don't think that pm2 is the right tool to build this "Hypervisor" architecture because it is more CLI oriented. I am not sure it will work well as an embedded library, but I have to do more research. Plus, building a process manager is not an easy task. It might introduce complexity in the codebase which requires people to maintain. "Single Application" architecture is simpler and therefore more sustainable.

Notice that the wot architecture spec does not specify which "architecture" a servient should support. It is left open-ended on purpose. So both "Single Application" and "Hypervisor" are valid servient implementations.

About your request. I am afraid it won't happen soon. We had a similar use case and we solved these requirements by treating the servient and the script as a single application (see again my my comment. Now you can use docker or pm2 as managing runtime (i.e. logs, start, stop, etc.). Do you think it will work also in your case?

[miguelrk]

Thanks @relu91 for the thorough response!

I have been thinking about it (and the links and comments you mention) and I do agree adding this functionality to node-wot might be out of scope. Appart from maintainability issues, a Hypervisor-based approach could quickly explode in complexity, and at the end, there are many other ways of deploying (WoT) scripts (e.g. as containers, serverless, in the cloud, locally, etc). Single-application servient makes sense for node-wot and I guess specific implementations using node-wot as a dependency should part from that point onwards.

As for myself, I would still require the stopping and monitoring features for my master-thesis (wot-runtime) despite it not being implemented in node-wot. The goal of wot-runtime (private repo for now) is to provide a WoT runtime manager to make it easier to deploy, manage and monitor multiple WoT runtimes, each with ability to deploy multiple scripts (each in its own Script Execution Context).

After much thought, I will most probably re-implement the runScript functionality and add both stopScript and getMonitoringInfo features programatically using pm2. This might be too much dependancy bloat for node-wot, but I will most definitively publish my approach here once I have it 👍