-
Epic
-
Resolution: Unresolved
-
Minor
-
None
-
None
-
None
-
Dynamic Sharding Adaptation on Shard Count Changes (SHARD env var and/or replicaSet removal)
-
False
-
-
False
-
SECFLOWOTL-88 - Augment Argo-CD sharding capabilities by implementing additional sharding algorithms
-
-
Story (Required)
As an Argo-CD administrator, I want the sharding algorithm to adapt dynamically when the number of shards changes. The algorithm should automatically reshuffle the cluster-to-shard mapping to maintain a balanced workload distribution. This will eliminate the need for manual intervention and ensure stability and optimal performance even during scaling events.
Amongst manual intervention, there is the requirement to set the ARGOCD_APPLICATION_CONTROLLER_REPLICAS environment variable and to scale the replicasSet.
Background (Required)
Currently, scaling the application controller requires to scale the replicas-set and to update environment variable ARGOCD_APPLICATION_CONTROLLER_REPLICAS . The two values must match and inconsistent behaviours may happen if they not.
Now that the distributionFunction for sharding has been updated, it could be possible to propose an implementation that will listen for the replicas count change and perform the required actions. Possible action could be:
- dumbly restarting each pod (this could match also by the project of replacing the replicaSet with a deployment). Each pod would listen for replicas count change and adjust its configuration dynamically.
Out of scope
Approach (Required)
This may required another change in the sharding mechanism and the creation of channel for which "replicas count change aware" implementation may listen.
Dependencies
Acceptance Criteria (Mandatory)
The use of env var ARGOCD_APPLICATION_CONTROLLER_REPLICAS is not required and deleted from documentation.
When the number of replicas of application-controller changes, logs in each pod must display the information and implementations will react on this.
Done Checklist
- Code is completed, reviewed, documented and checked in
- Unit and integration test automation have been delivered and running cleanly in continuous integration/staging/canary environment
- Continuous Delivery pipeline(s) is able to proceed with new code included
- Customer facing documentation, API docs etc. are produced/updated, reviewed and published
- Acceptance criteria are met