<p>I have a small Hazelcast cluster running inside Openshift 4(kubernetes) in a number of pods. My problem is that when I roll out a new version, sometimes I need to change the configuration of the hazelcast instances in the new version. The problem then arises because the pods and the old cluster is still running, because the new pods aren't started yet properly yet. The new upgraded members will fail because their configurations are incompatible with the running cluster (The old pods). We are using the headless service discovery type described here. <a href="https://github.com/hazelcast/hazelcast-kubernetes" rel="nofollow noreferrer">https://github.com/hazelcast/hazelcast-kubernetes</a>. The data in the hazelcast cluster can be deleted between deployments, we have no need to keep anything from the old cluster when we start a new one.</p>
<p>I would like a way to tell the new members and the old members to either ignore their differences, start them up as two seperate clusters that don't find each other, or simply not replicate between the old and new members at all.</p>
<p>I have looked into the portable serialization feature <a href="https://docs.hazelcast.com/imdg/4.1.2/serialization/implementing-portable-serialization" rel="nofollow noreferrer">https://docs.hazelcast.com/imdg/4.1.2/serialization/implementing-portable-serialization</a> but it strikes me as overkill, as we don't need the cluster data to survive between deployments. I'm also unsure if it will help when we change something in the configuration for the hazelcast instances, which will make the clusters incompatible.</p>
<p>Lastly, I considered changing the deployment strategy for kubernetes so the old pods are killed before the new pods start up, but that will cause downtime for the application when we deploy, which is not great.</p>

Martin Nielsen
<p>Some parts of the Hazelcast configuration cannot be configured at runtime, which means that you won't be able to do the rolling upgrade. In other words, you won't be able to have a cluster with members running with different configurations at the same time.</p>
<p>If the data is not important to you, then you can always use blue/green deployment, meaning that you first start the whole new cluster (with the new configuration), switch to the new cluster, and then stop the old cluster.</p>
