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, MachineConfigPool based matching is turned on
for the given `recommend:` list item. `<mcLabels>` specifies the labels
for a MachineConfig. The MachineConfig is created automatically to apply host settings, such as
kernel boot parameters, for the profile `<tuned_profile_name>`. This involves
finding all MachineConfigPools with machineConfigSelector matching
`<mcLabels>` and setting the profile `<tuned_profile_name>` on all nodes that
match the MachineConfigPools' `nodeSelectors`.

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`, `machineConfigLabels` item is not considered.


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

.Example: Node/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 MachineConfigPool's `nodeSelector` will match, then create the
Tuned CR above and finally create the custom MachineConfigPool 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