Hi @AharonIsraelCohen,
You mean, ability to have separate "resource" (CPU/Memory requests/limits)?

@drivebyer you can assign me

Hi @AharonIsraelCohen, You mean, ability to have separate "resource" (CPU/Memory requests/limits)?

@drivebyer you can assign me

Exactly, so on cases like increasing resources we could increase follower resources first and after the cluster is balanced, to increase leaders resources as well.

After thinking of this, I think we didn't need an additional field to separate resources for leader and follower. Because the actual role of Redis will change after cluster failover. That is to say, the pod under the leader statefulset may become a follower. So the additional field will be set to the wrong pod after cluster failover.

In your case, I think we need another way to enhance the data security. @AharonIsraelCohen

cc @husnialhamdani

After thinking of this, I think we didn't need an additional field to separate resources for leader and follower. Because the actual role of Redis will change after cluster failover. That is to say, the pod under the leader statefulset may become a follower. So the additional field will be set to the wrong pod after cluster failover.

In your case, I think we need another way to enhance the data security. @AharonIsraelCohen

cc @husnialhamdani

In my opinion it's still makes sense, to support resiliency/availability to the cluster, like we can make resources adjusment on the fly, by updating the follower first and then the leader (vice versa), follower can be temporarily become leader and then leader can takeover back after we patched the resources.