<commit_before>Feature: Rebalancing
  In order to have efficient use of resources
  As a user of northscale data persistence product
  I want to data to be rebalanced correctly during pool changes

  Scenario: Add 2nd node
    Given there is a pool P
    And pool P has node A hashed at point 20
    When new node X starts joining P at point 30
    Then node X should request snapshot for arc 20 to 30 from node A
    And no other request for arc snapshots should happen

  Scenario: Add 2nd node before the 1st in the ring
    Given there is a pool P
    And pool P has node A hashed at point 20
    When new node X starts joining P at point 10
    Then node X should request snapshot for arc 20 to 10 from node A
    And no other request for arc snapshots should happen

  Scenario: Add a node between others
    Given there is a pool P
    And pool P has node A hashed at point 20
    And pool P has node B hashed at point 40
    When new node X starts joining P at point 30
    Then node X should request snapshot for arc 20 to 30 from node B
    And no other request for arc snapshots should happen

  Scenario: After receiving an arc snapshot
    Given there is a pool P
    And pool P has node A hashed at point 20
    And new node X starts joining pool P at point 30
    And node X requests arc snapshot for 20 to 30 from node A
    And update deltas still happen to arc 20 to 30 on node A
    When X has received and processed the snapshot for arc 20 to 30 from node A
    Then node X should send an arc 20 to 30 takeover message to node A
    And node A sends any update deltas for arc 20 to 30 to node X
    And node A should proxy any requests into arc 20 to 30 to node X

# adding new nodes while arcs are being requested
# adding new nodes while arcs are being taken over<commit_msg>scenario outline examples for simple node additions<commit_after>Feature: Rebalancing
  In order to have efficient use of resources
  As a user of northscale data persistence product
  I want to my data to be rebalanced correctly during pool changes

  Scenario Outline: Add 2nd node
    Given a pool P with 1 hashpoint per node, and replication num 1
    And P has node A at hashpoint <a_hashpoint>
    When new node X starts joining P at hashpoint <x_hashpoint>
    Then X should request a snapshot for arc <arc> from A
    And no other request for arc snapshots should happen
    Examples:
      | a_hashpoint | x_hashpoint | arc     | comment  |
      |    20       |    30       | (20,30] | after-A  |
      |    20       |    10       | (20,10] | before-A |

  Scenario Outline: Add a node between 2 others
    Given a pool P with 1 hashpoint per node, and replication num 1
    And P has node A at hashpoint <a>
    And P has node B at hashpoint <b>
    When new node X starts joining P at hashpoint <x>
    Then X should request a snapshot for arc <arc> from <arc_src>
    And no other request for arc snapshots should happen
    Examples:
      | a  | b  | x  | arc     | arc_src |
      | 20 | 40 | 30 | (20,30] | B       |
      | 20 | 40 | 10 | (40,10] | A       |
      | 20 | 40 | 50 | (40,50] | A       |

  Scenario: After receiving an arc snapshot, with no other traffic
    Given a pool P with 1 hashpoint per node, and replication num 1
    And P has node A at hashpoint 20
    And new node X starts joining P at hashpoint 30
    And X requests a snapshot for arc (20,30] from A
    When X has received and processed the snapshot for (20,30] from A
    Then X should send an (20,30] takeover message to A
    And A should proxy any requests for (20,30] to X
    And A should respond to the (20,30] takeover request

  Scenario: After receiving an arc snapshot, with concurrent traffic
    Given a pool P with 1 hashpoint per node, and replication num 1
    And P has node A at hashpoint 20
    And new node X starts joining P at hashpoint 30
    And X requests a snapshot for arc (20,30] from A
    And update commands still happen on (20,30] on A
    And X starts receiving the snapshot for (20,30] from A
    When X starts has finished processing the snapshot for (20,30] from A
    Then X should send an (20,30] takeover message to A
    And A should send any interim update deltas for (20,30] to X
    And A should proxy any requests for (20,30] to X
    And A should reply with success to the (20,30] takeover request

# adding new nodes while arcs are being requested
# adding new nodes while arcs are being taken over
# flapping nodes
# nodes taking forever during a step
# nodes dying during a step
# stampede after power failure and restart
## need backoff?
# explicit node removal versus node dying or going through a reboot
# crappy network that's fast between some nodes and slow between others (not-same-rack)
# cutting arcs into smaller transfer parts?
{'fraction_non_alphanumeric': 0.032413216227519866, 'fraction_numerical': 0.03617733166039314, 'mean_word_length': 2.832532051282051, 'pattern_counts': {'":': 0, '<': 11, '<?xml version=': 0, '>': 11, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '94871', 'n_tokens_mistral': 1431, 'n_tokens_neox': 1267, 'n_words': 818}