User Story 2-3: Upgrades

[OmerMajNition]

One very common use case would be feature additions to reusable reactors. This would lead to a new version of components available and users could opt to switch to a newer version available. This user story would cover seamless upgrades to newer versions of components. For example, based on some new research cache component is upgraded with a new eviction algorithm available to users that decreases the write amplification on SSD with a comparable miss ratio performance. Users may want to use this newer eviction algorithm now available to save their SSD devices from erosion, improving their overall running cost. This would require them to upgrade their cache reactors already running in the production environment.

Similarly we can publish Servers that now support CXL devices (DRAM devices over CXL network), or NAS devices. Users may want to upgrade their existing Servers to make use of new storage devices available. Following diagram shows how an update in Server capabilities would let users select a different storage medium for their caches. POP-1 Server gets updated to use SSD as L1 cache and NAS as L2 cache.

Note: While we upgrade to a newer version of a reactor, we should let users decide the migration from old reactor to the new reactor. Users should be able to decide which states would be flushed and which would be migrated to the new reactor.

Implementation Considerations:
Which reactors should we allow for updates is a question. Reactors running as separate federates are easier to upgrade, it would mean to have an incoming reactor as a federate getting into the topology in place of an outgoing federate reactor. What about updating a non-federated reactor, do we migrate the state of the whole process?