Comment on page

LinuxConfigurator Operator

The LinuxConfigurator operator allows configuring systems tuned by Akamas by applying parameters related to the Linux kernel using different strategies.
The operator can configure provided Components or can configure every Component which has parameters related to the Linux kernel.
The parameters are applied via SSH protocol.
Using
In the most basic use of the Operator, it is sufficient to add a task of type LinuxConfigurator in the workflow.
- name: LinuxConf
  operator: LinuxConfigurator
  arguments:
    component: ComponentName
The operator makes use of properties specified in the component to identify which instance should be configured, how to access it, and any other information required to apply the configuration.
Operator arguments
Name
Type
Value restrictions
Required
Default
Description
component
String
It should match the name of an existing Component of the System under test
No
​
The name of the Component for which available Linux kernel parameters will be configured
If no component is provided, this operator will try to configure every parameter defined for the Components of the System under test
Supported Component Properties
The following table highlights the properties that can be specified on components and are used by this operator.
Name
Type
Value restrictions
Required
Default
Description
hostname
String
It should be a valid SSH host address
Yes
​
SSH host address
sshPort
Integer
1≤sshPort≤65532
Yes
22
SSH port
username
String
​
Yes
​
SSH login username
key
Multiline string
​
Either key or password is required
​
SSH login key, provided directly its value or the path of the file to import from. The operator supports RSA and DSA Keys
password
String
​
Either key or password is required
​
​
blockDevices
List of objects
It should have a structure like the one described in the next section​
No
​
Allows the user to restrict and specify to which block-device apply block-device-related parameters
networkDevices
List of objects
It should have a structure like the one described in the next section​
No
​
Allows the user to restrict and specify to which network-device apply network-device-related parameters
Filter parameters and block/network devices
The properties blockDevices and networkDevices allow specifying which parameters to apply to each block/network-device associated with the Component, as well as which block/network-device should be left untouched by the LinuxConfigurator.
If the properties are omitted, then all block/network-devices associated with the Component will be configured will all the available related parameters.
All block-devices called loopN (where N is an integer number greater or equal to 0) are automatically excluded from the Component’s block-devices
The properties blockDevices and networkDevices are lists of objects with the following structure:
Name
Type
Value restrictions
Required
Default
Description
name
String
It should be a valid regular expression to match block/network-devices
Yes
​
A regular expression that matches block/network-devices to configure with related parameters of the Component
parameters
List of strings
It should contain the names of matching parameters of the Component
No
​
The list of parameters to be configured for the specified block/network-devices. If the list is empty, then no parameter will be applied for the block/network-devices matched by name
Examples
blockDevices:
- name: "xvd[a-z]"
  parameters:
    - os_StorageReadAhead
    - os_StorageQueueScheduler
In this example, only the parameters os_StorageReadAhead and os_StorageQeueuScheduler are applied to all the devices that match the regex "xvd[a-z]" (i.e. xvda, xvdb, …, xvdc).
blockDevices:
- name: "xvdb|loop0"
  parameters:
    - os_StorageMaxSectorsKb
In these examples, only the parameter os_StorageMaxSectorKb is applied to block device xvdb and loop0.
Note that the parameter is applied also to the block device loop0, since it is specified in the name filter, this overrides the default behavior since loopN devices are excluded by the Linux Optimization Pack
networkDevices:
  - name: wlp4s0
    parameters: []
In this example, no parameters are applied to the wlp4s0 network device, which is therefore excluded from the optimization.
How are parameters applied to the system?
To support the scenario in which some configuration parameters related to the Linux kernel may be applied using the strategies supported by this operator, while others with other strategies (e.g, using a file to be written on a remote machine), it is necessary to specify which parameters should be applied with the LinuxConfigurator, and this is done at the ComponentType level; moreover, still at the ComponentType level, it is necessary to specify which strategy should be used to configure each parameter. This information is already embedded in the Linux Optimization pack and, usually, no customization is required.
Sysctl strategy
With this strategy, a parameter is configured by leveraging the sysctl utility. The sysctl variable to map to the parameter that needs to be configured is specified using the key argument.
name: Component Type 1
description: My Component type
parameters:
  - name: net_forwarding
    domain:
      type: integer
      domain: [0, 1]
    defaultValue: 1
    operators:
      # the parameter is configured using LinuxConfigurator
      LinuxConfigurator:
        sysctl:
          key: net.ipv4.forwarding
Echo strategy
With this strategy, a parameter is configured by echoing and piping its value into a provided file. The path of the file is specified using the file argument.
name: Component Type 1
description: My Component type
parameters:
  - name: os_MemoryTransparentHugepageEnabled
    domain:
      type: categorical
      categories: [always, never]
    defaultValue: always
    operators:
      LinuxConfigurator:
        echo:
          file: /sys/kernel/mm/transparent_hugepage/enabled
Map strategy
With this strategy, each possible value of a parameter is mapped to a command to be executed on the machine the LinuxConfigurator operates on(this is especially useful for categorical parameters).
name: Component Type 1
description: My Component type
parameters:
  - name: os_MemorySwap
    domain:
      type: categorical
      categories: [swapon, swapoff]
    defaultValue: swapon
    operators:
      LinuxConfigurator:
        map:
          swapon: command1
          swapoff: command2
Command strategy
With this strategy, a parameter is configured by executing a command into which the parameter value is interpolated.
name: Component Type 1
description: My Component type
parameters:
  - name: os_MemorySwap
    domain:
      type: categorical
      categories: [swapon, swapoff]
    defaultValue: swapon
    operators:
      LinuxConfigurator:
        command:
          cmd: sudo ${value} -a

FileConfigurator Operator

WindowsExecutor Operator

Last modified 4mo ago

Name	Type	Value restrictions	Required	Default	Description
`component`	String	It should match the name of an existing Component of the System under test	No		The name of the Component for which available Linux kernel parameters will be configured

Name	Type	Value restrictions	Required	Default	Description
`name`	String	It should be a valid regular expression to match block/network-devices	Yes		A regular expression that matches block/network-devices to configure with related parameters of the Component
`parameters`	List of strings	It should contain the names of matching parameters of the Component	No		The list of parameters to be configured for the specified block/network-devices. If the list is empty, then no parameter will be applied for the block/network-devices matched by `name`