After https://github.com/golemcloud/golem/issues/1034 each specific component version has an ordered list of active plugins. Taking the only the component transformers from this list, when compiling and instantiating a component WASM, we have to apply these transformations in order to get a final WASM.
This needs to be done in worker-executor-base, with it will work properly even with the precompilation in the component compilation service.
Immutability
With this solution the set of active plugins are static for a given component version. This means that changing the plugin configuration will create a new component version, and by it automatically leaves the existing workers as they are, but new workers are created with the new configuration. This is also compatible with the existing compilation cache where we can apply the transformations and compile the WASM to native code and safely store that associated with a given component version.
What happens if the plugin itself changes, and it no longer emits the same transformed component? (Unlike with oplog processors, we don't have full control of this because the transfomers are external web hooks).
I propose the simplest solution for Golem 1.1:
We assume that the component transfomer plugins are not changed arbitrarily so we are safe to cache the outcome
The plugin developers must register a new version of the plugin if it gets updated
The set of active plugins per component are pointing to specific versions of the plugins, so to update to a new component processor it needs to be changed, which ends up in a new component version, with all the existing guarantees (old workers continue running, update is possible via the update API, etc)
After https://github.com/golemcloud/golem/issues/1034 each specific component version has an ordered list of active plugins. Taking the only the component transformers from this list, when compiling and instantiating a component WASM, we have to apply these transformations in order to get a final WASM.
This needs to be done in
worker-executor-base, with it will work properly even with the precompilation in the component compilation service.Immutability
With this solution the set of active plugins are static for a given component version. This means that changing the plugin configuration will create a new component version, and by it automatically leaves the existing workers as they are, but new workers are created with the new configuration. This is also compatible with the existing compilation cache where we can apply the transformations and compile the WASM to native code and safely store that associated with a given component version.
What happens if the plugin itself changes, and it no longer emits the same transformed component? (Unlike with oplog processors, we don't have full control of this because the transfomers are external web hooks).
I propose the simplest solution for Golem 1.1: