Edit (Data Store Placement Policy)

Description

The edit operation initiates an asynchronous job that sets or modifies the node affinity and tolerations for a system-managed datastore's pods. Node affinity allows for pods to be scheduled to nodes that have matching label key-value pairs, whereas tolerations allow for pods to be scheduled on tainted nodes that would otherwise repel them if not for matching toleration and taint key-value pairs. For more information on configuring the nodeAffinity and tolerations properties, see the Node affinity and Tolerations sections below.

Node affinity

Before establishing node affinity, a label must be placed on an individual node or added to node pools so that newly created or recycled nodes inherit the same label. A label is comprised of key-value pairs (key=value) that attract specific pods to that node. This is done by configuring the nodeAffinity property of a datastore's pods to use the same label key and value information as the node. Below is the general JSON syntax for nodeAffinity:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
"nodeAffinity": {
  "<requiredDuringSchedulingIgnoredDuringExecution | preferredDuringSchedulingIgnoredDuringExecution>": {
    "nodeSelectorTerms": [
      {
        "matchExpressions": [
          {
            "key": "<label key>",
            "operator": "<In | NotIn | Exists | DoesNotExist>",
            "values": [
              "<label value>"
            ]
          }
        ]
      }
    ]
  }
}

The operator property shown above specifies the relationship between nodeAffinity properties and the node’s labels. The scheduler uses the key, values, and operator information, along with whether matching values are required or preferred, to determine where the datastore’s pods are scheduled.

For example, a node receives the following label:

1
kubectl label nodes exampleNode sampleLabel=sampleValue

and an administrator wants to require that the key (sampleLabel) and value (sampleValue) information is present on a datastore's pods in order for them to be scheduled to a specific node. To achieve that outcome, the nodeAffinity property would need to be configured with the exact key and value information applied to the node, as well as setting the requiredDuringSchedulingIgnoredDuringExecution property:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
"nodeAffinity": {
  "requiredDuringSchedulingIgnoredDuringExecution": {
    "nodeSelectorTerms": [
      {
        "matchExpressions": [
          {
            "key": "sampleLabel",
            "operator": "In",
            "values": [
              "sampleValue"
            ]
          }
        ]
      }
    ]
  }
}

Node affinity ensures that the scheduler will attempt to schedule pods with their matching nodes. However, it may not prevent other pods that do not have matching key-value pairs from being scheduled to labeled nodes. It will also not remove preexisting pods that have been scheduled to the node before the label was added. Administrators wanting to repel all pods that are not for a specific service may also want to taint the node.

Tolerations

Similarly to node affinity, tainting a node requires a key-value pair, as well as an effect, to be applied to a node. Applying a taint to a node ensures that all pods that do not tolerate the node are repelled from it and are scheduled to other available nodes instead. For a pod to tolerate a tainted node, the key, values, and effect properties under tolerations must either match the tainted values exactly or have only the key value be present in the tolerations property. Below is the general JSON syntax for tolerations:

1
2
3
4
5
6
7
8
"tolerations": [
  {
    "effect": "<NoExecute | NoSchedule | PreferNoSchedule>",
    "key": "<taint key>",
    "operator": "<Exists | Equal>",
    "value": "<taint value>"
  }
]

The table below defines the different values that can be assigned to the effect and operator properties:

To demonstrate how taints and tolerations interact, consider an administrator that wants to taint a node so that only tolerant pods are scheduled to the node, and that all preexisting pods on the node are expelled if they are not tolerant. To achieve this, a taint must first be applied to the node:

1
kubectl taint node exampleNode sampleKey=sampleValue:NoSchedule

The exact values of the key (sampleKey), value (sampleValue), and effect (NoSchedule) properties used to taint the node would need to used to configure the tolerations property:

1
2
3
4
5
6
7
8
"tolerations": [
  {
    "effect": "NoSchedule",
    "key": "sampleKey",
    "operator": "Equal",
    "value": "sampleValue"
  }
]

Tainting a node and assigning tolerations to a datastore's pods ensures that the node is reserved for the pods that need the node's specialized resources, and that other pods that do not need certain resources can run on standard nodes.

Request parameters

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
placementPolicyJson={
  "dataStoreType": "<nosql | memCacheStore | objectStore | egdb>",
  "dataStoreId": "<datastore ID>",
  "placementPolicy": {
    "tolerations": [
      {
        "effect": "<NoExecute | NoSchedule | PreferNoSchedule>",
        "key": "<taint key>",
        "operator": "<Exists | Equal>",
        "value": "<taint value>"
      }
    ],
    "nodeAffinity": {
      "<requiredDuringSchedulingIgnoredDuringExecution |
      preferredDuringSchedulingIgnoredDuringExecution>": {
        "nodeSelectorTerms": [
          {
            "matchExpressions": [
              {
                "key": "<label key>",
                "operator": "<In | NotIn | Exists | DoesNotExist>",
                "values": [
                  "<label value>"
                ]
              }
            ]
          }
        ]
      }
    }
  }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
placementPolicyJson={
  "dataStoreId":"793c65d9507e4b7baabecdeec9db8fd8",
  "placementPolicy":{
    "tolerations":[
      {
        "key":"nodepoolDS",
        "operator":"Equal",
        "value":"pool1",
        "effect":"NoSchedule"
      }
    ],
    "nodeAffinity":{
      "requiredDuringSchedulingIgnoredDuringExecution":{
        "nodeSelectorTerms":[
          {
            "matchExpressions":[
              {
                "key":"npool",
                "operator":"In",
                "values":["pool1"]
              }
            ]
          }
        ]
      }
    }
  },
  "dataStoreType":"egdb"
}

Example usage

The following is a sample POST request for the edit operation that demonstrates configuring tolerations for a datastore's pods:

1
2
3
4
5
6
POST /<context>/admin/data/793c65d9507e4b7baabecdeec9db8fd8/config/placementPolicy/edit HTTP/1.1
Host: organization.example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: []

placementPolicyJson={"dataStoreId":"793c65d9507e4b7baabecdeec9db8fd8","placementPolicy":{"tolerations":[{"key":"nodepoolDS","operator":"Equal","value":"pool1","effect":"NoSchedule"}],"nodeAffinity":{"requiredDuringSchedulingIgnoredDuringExecution":{"nodeSelectorTerms":[{"matchExpressions":[{"key":"npool","operator":"In","values":["pool1"]}]}]}}},"dataStoreType":"egdb"}&f=pjson&token=Mb0ORrkLObNO2Q8FZoUCHHzSMzZi0CbhLHNRYMqqa6URG_ojQJF3rNsJAfRB23MyCrLwSmuaHPUo4AEIrUuoH1-4Ot5xh4565FtlQahXAhK2C7Sy0oydZhBwD8KdFSnVlnLr-e9uI5ovSWZ2lGNn9SwoV2MPMzeAh_5r-q-wgwF8DTT_nhuCXJGkMRy-48jjGS2aN5FI18STHZ8RAuKxGasH90SI3C7njZzlGCUrY5m6BDhCMsdpZA14GwNX8Cis

JSON Response

The following is a sample JSON response for the edit operation. You can use the jobid property to track the asynchronous job's status and progress by querying the Job resource.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
{
  "updatedtime": 1761332659745,
  "jobid": "j008f5460-a6ab-45f9-b712-5dd595cc4187",
  "resource": {"name": "793c65d9507e4b7baabecdeec9db8fd8"},
  "requestID": "f8e67fc1-9e5f-44be-b3bd-0b58b3c27770",
  "name": "updateDataStorePlacementPolicy",
  "endtime": 0,
  "progress": {"stages": [
    {
      "name": "validating",
      "state": "in_progress"
    },
    {
      "name": "applying",
      "state": "not_started"
    }
  ]},
  "starttime": 1761332659730,
  "operationURI": "/arcgis/admin/data/793c65d9507e4b7baabecdeec9db8fd8/config/placementPolicy/edit",
  "status": "EXECUTING",
  "username": "administrator"
}

The following is a sample JSON response for a successfully completed edit operation.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
{
  "result": {"updateDataStorePlacementPolicy": {
    "tolerations": [{
      "effect": "NoSchedule",
      "value": "pool1",
      "key": "nodepoolDS",
      "operator": "Equal"
    }],
    "nodeAffinity": {
      "requiredDuringSchedulingIgnoredDuringExecution": {"nodeSelectorTerms": [{"matchExpressions": [{
        "values": ["pool1"],
        "key": "npool",
        "operator": "In"
      }]}]}
    }
  }},
  "updatedtime": 1761330072753,
  "jobid": "j008f5460-a6ab-45f9-b712-5dd595cc4187",
  "resource": {"name": "793c65d9507e4b7baabecdeec9db8fd8"},
  "requestID": "f8e67fc1-9e5f-44be-b3bd-0b58b3c27770",
  "name": "updateDataStorePlacementPolicy",
  "endtime": 1761330072756,
  "progress": {"stages": [
    {
      "name": "validating",
      "state": "completed"
    },
    {
      "name": "applying",
      "state": "completed"
    }
  ]},
  "starttime": 1761332659730,
  "operationURI": "/arcgis/admin/data/793c65d9507e4b7baabecdeec9db8fd8/config/placementPolicy/edit",
  "status": "COMPLETED",
  "username": "administrator"
}