In some cases, an in-place update is not possible. This is true for unusually large or complex changes to the fundamental functioning of the system.
It may also come a time where operators may wish to replace one of Replicante Core dependencies, which prevents a gradual rollout. This breaking updates process can be used for that too.
More then one Replicante Core cluster MUST not be managing the same datastore or actions generated by the different clusters may cause conflicts or issues.
During the initial phases of development, large breaking changes are needed more frequently.
Supporting the full gradual release process while the system is evolving this fast is also very costly so it is not done every time.
replicanteprocesses on the new cluster.
discoverybackend (or for groups of backends) configured on the existing cluster:
The process described above works because current data is either generated by the system or is historical data collected over time.
This will change once organisations are introduced and dynamic user content will be stored. When that happens, this process will be updated to support transferring user data across instances.