openshift-docs/modules/custom-tuning-specification.adoc

// Module included in the following assemblies:
//
// * scalability_and_performance/using-node-tuning-operator.adoc
// * post_installation_configuration/node-tasks.adoc

[id="custom-tuning-specification_{context}"]
= Custom tuning specification

The custom resource (CR) for the Operator has two major sections. The first section, `profile:`, is a list of Tuned profiles and their names. The second, `recommend:`, defines the profile selection logic.

Multiple custom tuning specifications can co-exist as multiple CRs in the Operator's namespace. The existence of new CRs or the deletion of old CRs is detected by the Operator. All existing custom tuning specifications are merged and appropriate objects for the containerized Tuned daemons are updated.

*Management state*

The Operator Management state is set by adjusting the default Tuned CR. By default, the Operator is in the Managed state and the `spec.managementState` field is not present in the default Tuned CR. Valid values for the Operator Management state are as follows:

  * Managed: the Operator will update its operands as configuration resources are updated
  * Unmanaged: the Operator will ignore changes to the configuration resources
  * Removed: the Operator will remove its operands and resources the Operator provisioned

*Profile data*

The `profile:` section lists Tuned profiles and their names.

[source,yaml]
----
profile:
- name: tuned_profile_1
  data: |
    # Tuned profile specification
    [main]
    summary=Description of tuned_profile_1 profile

    [sysctl]
    net.ipv4.ip_forward=1
    # ... other sysctl's or other Tuned daemon plugins supported by the containerized Tuned

# ...

- name: tuned_profile_n
  data: |
    # Tuned profile specification
    [main]
    summary=Description of tuned_profile_n profile

    # tuned_profile_n profile settings
----

*Recommended profiles*

The `profile:` selection logic is defined by the `recommend:` section of the CR. The `recommend:` section is a list of items to recommend the profiles based on a selection criteria.

[source,yaml]
----
recommend:
<recommend-item-1>
# ...
<recommend-item-n>
----

The individual items of the list:

[source,yaml]
----
- machineConfigLabels: <1>
    <mcLabels> <2>
  match: <3>
  <match> <4>
  priority: <priority> <5>
  profile: <tuned_profile_name> <6>
----
<1> Optional.
<2> A dictionary of key/value `MachineConfig` labels. The keys must be unique.
<3> If omitted, profile match is assumed unless a profile with a higher priority matches first or `machineConfigLabels` is set.
<4> An optional list.
<5> Profile ordering priority. Lower numbers mean higher priority (`0` is the highest priority).
<6> A Tuned profile to apply on a match. For example `tuned_profile_1`.

`<match>` is an optional list recursively defined as follows:

[source,yaml]
----
- label: <label_name> <1>
  value: <label_value> <2>
  type: <label_type> <3>
  <match> <4>
----
<1> Node or pod label name.
<2> Optional node or pod label value. If omitted, the presence of `<label_name>` is enough to match.
<3> Optional object type (`node` or `pod`). If omitted, `node` is assumed.
<4> An optional `<match>` list.

If `<match>` is not omitted, all nested `<match>` sections must also evaluate to `true`. Otherwise, `false` is assumed and the profile with the respective `<match>` section will not be applied or recommended. Therefore, the nesting (child `<match>` sections) works as logical AND operator. Conversely, if any item of the `<match>` list matches, the entire `<match>` list evaluates to `true`. Therefore, the list acts as logical OR operator.

If `machineConfigLabels` is defined, machine config pool based matching is turned on for the given `recommend:` list item. `<mcLabels>` specifies the labels for a machine config. The machine config is created automatically to apply host settings, such as kernel boot parameters, for the profile `<tuned_profile_name>`. This involves finding all machine config pools with machine config selector matching `<mcLabels>` and setting the profile `<tuned_profile_name>` on all nodes that match the machine config pools' node selectors.

The list items `match` and `machineConfigLabels` are connected by the logical OR operator. The `match` item is evaluated first in a short-circuit manner. Therefore, if it evaluates to `true`, the `machineConfigLabels` item is not considered.

[IMPORTANT]
====
When using machine config pool based matching, it is advised to group nodes with the same hardware configuration into the same machine config pool. Not following this practice might result in Tuned operands calculating conflicting kernel parameters for two or more nodes sharing the same machine config pool.
====

.Example: node or pod label based matching
[source,yaml]
----
- match:
  - label: tuned.openshift.io/elasticsearch
    match:
    - label: node-role.kubernetes.io/master
    - label: node-role.kubernetes.io/infra
    type: pod
  priority: 10
  profile: openshift-control-plane-es
- match:
  - label: node-role.kubernetes.io/master
  - label: node-role.kubernetes.io/infra
  priority: 20
  profile: openshift-control-plane
- priority: 30
  profile: openshift-node
----

The CR above is translated for the containerized Tuned daemon into its `recommend.conf` file based on the profile priorities. The profile with the
highest priority (`10`) is `openshift-control-plane-es` and, therefore, it is considered first. The containerized Tuned daemon running on a given node looks to see if there is a pod running on the same node with the `tuned.openshift.io/elasticsearch` label set. If not, the entire `<match>` section evaluates as `false`. If there is such a pod with the label, in order for the `<match>` section to evaluate to `true`, the node label also needs to be `node-role.kubernetes.io/master` or `node-role.kubernetes.io/infra`.

If the labels for the profile with priority `10` matched, `openshift-control-plane-es` profile is applied and no other profile is considered. If the node/pod label combination did not match, the second highest priority profile (`openshift-control-plane`) is considered. This profile is applied if the containerized Tuned pod runs on a node with labels `node-role.kubernetes.io/master` or `node-role.kubernetes.io/infra`.

Finally, the profile `openshift-node` has the lowest priority of `30`. It lacks the `<match>` section and, therefore, will always match. It acts as a profile catch-all to set `openshift-node` profile, if no other profile with higher priority matches on a given node.

image::node-tuning-operator-workflow-revised.png[Decision workflow]

.Example: MachineConfigPool based matching
[source,yaml]
----
apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  name: openshift-node-custom
  namespace: openshift-cluster-node-tuning-operator
spec:
  profile:
  - data: |
      [main]
      summary=Custom OpenShift node profile with an additional kernel parameter
      include=openshift-node
      [bootloader]
      cmdline_openshift_node_custom=+skew_tick=1
    name: openshift-node-custom

  recommend:
  - machineConfigLabels:
      machineconfiguration.openshift.io/role: "worker-custom"
    priority: 20
    profile: openshift-node-custom
----

To minimize node reboots, label the target nodes with a label the machine config pool's node selector will match, then create the Tuned CR above and finally create the custom machine config pool itself.

// $ oc label node <node> node-role.kubernetes.io/worker-custom=
// $ oc create -f <tuned-cr-above>
// $ oc create -f- <<EOF
// apiVersion: machineconfiguration.openshift.io/v1
// kind: MachineConfigPool
// metadata:
//   name: worker-custom
//   labels:
//     worker-custom: ""
// spec:
//   machineConfigSelector:
//     matchExpressions:
//       - {key: machineconfiguration.openshift.io/role, operator: In, values: [worker,worker-custom]}
//   nodeSelector:
//     matchLabels:
//       node-role.kubernetes.io/worker-custom: ""
// EOF