Updating tickets (#769, #774, #875, #889, #917, #920, #928, #929, #930, #931, #932, #933, #934, #935, #936, #938, #939, #940, #941, #942, #943, #944, #951, #958, #959, #960, #962, #630, #870, #891, #895)

If you require that the config should be the same, then you do require a fulll cluster shutdown for an upgrade since multiple versions can't co-exist next to each other. So something to keep in mind.

Another problem you have is with 'which configuration is leading'?

Could it be.. when an old node that has been shutdown for a long time.. comes up.. starts yelling to the cluster.. he guys.. this is the config we should use... you get the picture...

And if it is done based on version.. than you have the problem that when a customer decides to go a version back (e.g. new version no good etc) that the downgrade doesn't work since the older version will always be rejected to favor the higher version.

Currently, configuration is read only during start-up and changes are not propagated afterwards, i.e. there is no way of updating the configuration. For some settings (like serialization), differences between cluster nodes lead to loss of connectivity, other bugs will for sure be more subtle, so what is the plan for a configuration change in a running cluster?

Dynamic changing the config might be supported, but not now, later. It is a very hard problem since we might need to invalidate everything, every actor in the cluster. Might be easiest to just have an easy way of doing full cluster restart (rolling).