Story (Required)

As an Argo-CD administrator, I want the sharding algorithm to utilize selector-based affinities for workload distribution. The algorithm should consider affinity rules defined by users, allowing them to specify preferred shard assignments based on specific attributes or labels. By leveraging these affinities, the algorithm will distribute workloads to shards that match the defined criteria, giving the ability to reduce network latency and improving overall system performance.

Background (Required)

This feature could be interesting for a GitOps Service having customers into different areas. Even if the network load is not that important, when the number of clusters to manage reaches an high value, this could have some impacts on response time.

The affinity should be also a "best-effort" mode, meaning that no cluster should be let unassigned because the provided labels are not satisfied.

Depending on users adoption, it could interesting to have hard requirements labels that can be used for security placement reasons (dmz, fw, vpc, etc...) . But that's another story

Out of scope

The affinity should be also a "best-effort" mode, meaning that no cluster should be let unassigned because the provided labels are not satisfied.

Approach (Required)

there should be a "selectorBasedDistributionFunction" which would accept a cluster if it matches the label. Given the requirement of no orphan clusters, it could be required to have a way to forcibly assign a cluster to a shard. 

Dependencies

GITOPSRVCE-611

Acceptance Criteria (Mandatory)

Pay attention to assign all the clusters to a shard even if the selector does not match.

INVEST Checklist

Dependencies identified

Blockers noted and expected delivery timelines set

Design is implementable

Acceptance criteria agreed upon

Story estimated

Legend

Unknown

Verified

Unsatisfied

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