Uploaded image for project: 'OpenShift GitOps'
  1. OpenShift GitOps
  2. GITOPS-3584

Minimize clusters reshuffling when sharding configuration changes with round-robin algorithm

XMLWordPrintable

    • Minimize cluster shuffling
    • False
    • None
    • False
    • SECFLOWOTL-88 - Augment Argo-CD sharding capabilities by implementing additional sharding algorithms
    • 0% To Do, 0% In Progress, 100% Done
    • Hide
      This enhancement allows users to use an alternative sharding algorithm based on Consistent hashing with bounded loads algorithm. The algorithm distributes uniformly managed clusters accros shards and it minimizes reshuffling in case a configuration change (increase or decrease of the number of managed clusters or the number of shards).

      Show
      This enhancement allows users to use an alternative sharding algorithm based on Consistent hashing with bounded loads algorithm. The algorithm distributes uniformly managed clusters accros shards and it minimizes reshuffling in case a configuration change (increase or decrease of the number of managed clusters or the number of shards).
    • GITOPS Core Sprint 3248, GITOPS Core Sprint 3250, GITOPS Core Sprint 3252

      Story (Required)

      As an ArgoCD user, I want that cluster reshuffling is minimal when the sharding configuration changes.

      Background (Required)

      The round-robin sharding algorithm sorts the clusters based on their uid. Then, they are put in an array and distributed evenly using a modulo operation accross all shards.

      If cluster at index 0 is removed, it means that all the clusters will be redistributed accross the shards. That's a lot of movement inducing context switching, potentially caches rebuild etc... and thus potential performance overhead.

       

       

      Out of scope

      <Defines what is not included in this story>

      Approach (Required)

      Look for research papers treating this problem and determine if existing algortihms does not exist?

      Another simple approach could be to implement a time to leave or placement expiracy policy where the reshuffle only happens when the tick is reached.

      Dependencies

       

      Acceptance Criteria (Mandatory)

      The described naive case should be successful: No reshuffling in case of the remove of the first cluster.

      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

            abenaiss Akram Ben Aissi
            abenaiss Akram Ben Aissi
            GitOps
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: