Currently the sequential roll pods logic will target the replica index of a shard to roll first before moving onto the primary.
|
for nodeIndex := nodesPerShard - 1; nodeIndex >= 0; nodeIndex-- { |
Given that the role can change during the lifecycle of the cluster, this may not always be the current replica.
This should be enhanced such that all replicas are rolled first before moving onto the primary.
This could be retrieved via the Status.Role of the ValkeyNodes for a shard, however that check may need to be enhanced.
Perhaps a new function getReplicasForShard and getPrimaryForShard could be introduced.
Perhaps a preStop script for the pods can be introduced to invoke a CLUSTER FAILOVER if the pod is priamry, and await for reconciliation can be added.
Currently the sequential roll pods logic will target the replica index of a shard to roll first before moving onto the primary.
valkey-operator/internal/controller/valkeycluster_controller.go
Line 430 in 6b6047f
Given that the role can change during the lifecycle of the cluster, this may not always be the current replica.
This should be enhanced such that all replicas are rolled first before moving onto the primary.
This could be retrieved via the Status.Role of the ValkeyNodes for a shard, however that check may need to be enhanced.
Perhaps a new function
getReplicasForShardandgetPrimaryForShardcould be introduced.Perhaps a preStop script for the pods can be introduced to invoke a
CLUSTER FAILOVERif the pod is priamry, and await for reconciliation can be added.