Apply a cluster layout

Compute the next layout from the full set of member roles and adopt it on this node; gossip carries it to every other node. Slots keep their node wherever it is still valid, so only the data that has to move does. The answer carries the versions the change retains, as a read right after would; a node they place data on is still serving it. With dry_run the computed layout and the number of slots that would move are returned without adopting anything. Returns 400 when the roles cannot produce a layout, e.g. fewer members with capacity than the widest width.

post/api/v1/cluster/layout

Request

Base URL: http://localhost:8090
URL: http://localhost:8090/api/v1/cluster/layout
Auth: none declared

Query parameters

dry_runboolean

Request body

widthsinteger[]

Slot prefixes to spread for: 3 for replicated data, k+m per erasure scheme. Default: the current layout's, else [3].

partitionsinteger

Partition count, a power of two. Only used for the first layout; default 256.

Example request

{
  "members": [
    {
      "id": "node-1",
      "zone": "dc1",
      "rack": "r1"
    }
  ]
}

Response

The computed layout and what it changes.

moved_slotsinteger required

Slots whose node differs from the current layout.

appliedboolean required

Example response

{
  "layout": {
    "members": [
      {
        "id": "node-1",
        "zone": "dc1",
        "rack": "r1"
      }
    ]
  }
}

Changes

No operation changes recorded.