The match section is used for assigning a device to a device class. It consists of conditions, which need to be unique among all device classes with the same parent class.

The structure of conditions is described here. The following example shows the match section of junos:

  logical_operator: OR
    - match_mode: startsWith
      type: SysObjectID
        - .
    - match_mode: contains
      type: SysDescription
       - kernel JUNOS
       - kernel Junos

This device class matches if the SysObjectID of a device starts with ‘.’ or if the SysDescription contains ‘kernel JUNOS’ or ‘kernel junos’.

The first thing Thola does when receiving a request for communicating with a new device is assigning that device to a device class. The algorithm for doing this works like this:

Every device class, except generic, has conditions in its match section. Thola goes through all top level device classes, which are all direct sub device classes of generic, and evaluates their conditions. As soon as the conditions of one device class return true, this device class will be used and all other classes whose conditions were not evaluated yet are ignored. If the matched device class has no sub classes, that device class will be used for communicating with the device. If there are sub classes, Thola will continue evaluating their conditions. If none of these classes match to the device, their parent which already matched before will be used as device class for the device. If one of the sub classes matches, Thola will go on recursively until a device class is determined. If none of the top level device classes match to a device, the generic class will be used.

This algorithm shows that in order for a device to be assigned to any device class, it also needs to fulfill the conditions of all parent device classes of this class. When creating a sub device class of an already existing class, it needs to be considered that devices will only be assinged to this class if they also meet all conditions of all parent device classes.