You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently adding a new scheduler interpreter, health interpreter or a new workflow (and probably many others) requires it to be programmed in the Nelson codebase. In the case where there is an internal deployment of a non-OSS component (e.g. an internal scheduler or a custom org-specific workflow) Nelson must be forked which incurs a high cost on users.
Instead one can imagine a plugin system where operators program against a specified interface and provide a compiled JAR which is then dynamically loaded by Nelson. The JAR and/or class can be specified in the Nelson config file by operators. While dynamic classloading is generally pretty sketchy, since this is solely done by operators it shouldn't be too bad.. hopefully.
The text was updated successfully, but these errors were encountered:
Currently adding a new scheduler interpreter, health interpreter or a new workflow (and probably many others) requires it to be programmed in the Nelson codebase. In the case where there is an internal deployment of a non-OSS component (e.g. an internal scheduler or a custom org-specific workflow) Nelson must be forked which incurs a high cost on users.
Instead one can imagine a plugin system where operators program against a specified interface and provide a compiled JAR which is then dynamically loaded by Nelson. The JAR and/or class can be specified in the Nelson config file by operators. While dynamic classloading is generally pretty sketchy, since this is solely done by operators it shouldn't be too bad.. hopefully.
The text was updated successfully, but these errors were encountered: