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’s dependencies, which prevents a gradual rollout. This process can be used for that too.
More then one Replicante 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.
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 transfering user data across instances.