<commit_before>.. index:: glossary

.. _glossary:

Glossary of terms
=================

..
   Please add new terms in alphabetical order and feel free to relocate
   existing terms to match. All terms are automatically added to the Sphinx
   index. Ensure that new terms added to the glossary are also linked from the
   body of the documentation. The glossary is a reference only, users are not
   expected to need to read the entire glossary to find the information. FIXME
   - need to add many more terms here

**A** [ :term:`action level` ] [ :term:`alias` ]

**C** [ :term:`chart` ] [ :term:`ci loop` ]

**D** [ :term:`device` ] [ :term:`device dictionary` ]
[ :term:`device owner` ] [:term:`device status transition` ]
[ :term:`device tag` ] [ :term:`device type` ] [ :term:`developer image` ]
[ :term:`dispatcher` ] [ :term:`distributed deployment`] [ :term:`DTB` ]
[ :term:`DUT` ]

**E** [ :term:`exclusive` ]

**F** [ :term:`frontend` ]

**H** [ :term:`hacking session` ] [ :term:`health check` ]
[:term:`hidden device type` ] [ :term:`hostname` ]

**I** [ :term:`inline` ] [ :term:`interface tag` ]

**J** [ :term:`jinja2`] [ :term:`job context` ] [ :term:`job definition` ]

**L** [ :term:`lxc` ]

**M** [ :term:`master` ] [ :term:`messageID` ] [ :term:`metadata` ]
[ :term:`MultiNode` ]

**O** [ :term:`offline` ]

**P** [ :term:`parameters` ] [ :term:`PDU` ] [ :term:`physical access` ]
[ :term:`pipeline` ] [ :term:`priority` ] [ :term:`production image` ]
[ :term:`prompts` ] [ :term:`protocol` ]

**Q** [ :term:`query` ]

**R** [ :term:`refactoring` ]
[ :term:`remote worker`]
[ :term:`restricted device` ]
[ :term:`results` ]
[ :term:`retired` ]
[ :term:`role` ] [ :term:`rootfs` ] [ :term:`rootfstype` ]

**S** [ :term:`scheduler` ]

**T** [ :term:`test run` ] [ :term:`test shell` ] [ :term:`tftp` ]

**V** [ :term:`VLANd` ]

**W** [ :term:`worker` ]

**Z** [ :term:`ZMQ` ]


.. glossary::

  action level
    The :term:`pipeline` is organised into sections and levels. The first
    section of the pipeline is given level 1. Sub tasks of that section start
    with level 1.1 and so on. Log files and job definitions will refer to
    actions using the level. Details of the action can then be accessed using
    the level as the location: ``job/8360/definition#2.4.5``

    .. seealso:: :ref:`pipeline_construction`

  alias
    A string which can be used to relate the descriptive device-type name to a
    particular list of aliases which could be used to lookup the matching
    device-type. This can be useful to list the :term:`device tree blobs <DTB>`
    which can be used with this device-type. (Aliases cannot be used in job
    submissions directly.) Multiple device-types are allowed to share the one
    or more aliases.

  chart
    A chart allows users to track :term:`results` over time using
    :term:`queries <query>`.

  ci loop
    Continous Integration (CI) typically involves repeated automated
    submissions using automated builds of the artifacts prompted by
    modifications made by developers. Providing feedback to the developers on
    whether the automated build passed or failed creates a loop. LAVA is
    designed as one component of a ci loop.

    .. seealso:: :ref:`ci_loop`, :ref:`continuous_integration` and
      :term:`metadata`

  device
    A device in LAVA is an instance of a :term:`device type`.

    * Test writers: see :term:`device tag`

    * Admins: see :ref:`create_device_database` and :term:`device dictionary`.

    * Developers: see :ref:`naming_conventions`

  device dictionary
    The device dictionary holds data which is specific to one device within a
    group of devices of the same device type. For example, the power control
    commands which reference a single port number. The dictionary itself is a
    key:value store within the LAVA server database which admins can modify to
    set configuration values according to the :term:`pipeline` design.

    .. seealso:: :ref:`create_device_dictionary` and
      :ref:`viewing_device_dictionary_content`.

  device owner
    A device owner has permission to change the status of a particular device
    and update the free text description of a device. Note that superusers of
    the LAVA instance are always able to submit jobs to and administer any
    devices on that instance.

    .. seealso:: :ref:`device_owner_help` and :ref:`owner_actions`.

  device status transition
    A record of when a device changed :ref:`device_status`, who caused the
    transition, when the transition took place as well as any message assigned
    to the transition. Individual transitions can be viewed in LAVA at
    ``<server>scheduler/transition/<ID>`` where the ID is a sequential integer.
    If the transition was caused by a job, this view will link to that job.

  device tag
    A tag is a device specific label which describes specific hardware
    capabilities of this specific device. Test jobs using tags will fail if no
    suitable devices exist matching the requested device tag or tags. Tags are
    typically used when only a proportion of the devices of the specified type
    have hardware support for a particular feature, possibly because those
    devices have peripheral hardware connected or enabled. A device tag can
    only be created or assigned to a particular device by a lab admin. When
    requesting tags, remember to include a description of what the tagged
    device can provide to a Test Job.

  device type
    The common type of a number of devices in LAVA. The device type may have a
    :term:`health check` defined. Devices with the same device type will run
    the same health check at regular intervals. See :ref:`device_types`.

  developer image
    A build of Android which, when deployed to a device, means that the device
    **is visible** to ``adb``. Devices configured this way will be able to have
    the image replaced using any machine, just be connecting a suitable cable,
    so these images are not typically deployed onto hardware which will be sold
    to the customer without having this image replaced with a production image.

    .. seealso:: :ref:`lava_lxc_protocol_android`

  dispatcher
    A machine to which multiple devices are connected. The dispatcher has
    ``lava-dispatcher`` installed and passes the commands to the device and
    other processes involved in running the LAVA test. A dispatcher does not
    need to be at the same location as the server which runs the scheduler. The
    term ``dispatcher`` relates to how the machine operates the
    ``lava-dispatch`` process using ``lava-slave``. The related term
    :term:`worker` relates to how the machine appears from the :term:`master`.

  distributed deployment
    A method of installing LAVA involving a single :term:`master` and one or<commit_msg>add a link to the device tag glossary entry<commit_after>.. index:: glossary

.. _glossary:

Glossary of terms
=================

..
   Please add new terms in alphabetical order and feel free to relocate
   existing terms to match. All terms are automatically added to the Sphinx
   index. Ensure that new terms added to the glossary are also linked from the
   body of the documentation. The glossary is a reference only, users are not
   expected to need to read the entire glossary to find the information. FIXME
   - need to add many more terms here

**A** [ :term:`action level` ] [ :term:`alias` ]

**C** [ :term:`chart` ] [ :term:`ci loop` ]

**D** [ :term:`device` ] [ :term:`device dictionary` ]
[ :term:`device owner` ] [:term:`device status transition` ]
[ :term:`device tag` ] [ :term:`device type` ] [ :term:`developer image` ]
[ :term:`dispatcher` ] [ :term:`distributed deployment`] [ :term:`DTB` ]
[ :term:`DUT` ]

**E** [ :term:`exclusive` ]

**F** [ :term:`frontend` ]

**H** [ :term:`hacking session` ] [ :term:`health check` ]
[:term:`hidden device type` ] [ :term:`hostname` ]

**I** [ :term:`inline` ] [ :term:`interface tag` ]

**J** [ :term:`jinja2`] [ :term:`job context` ] [ :term:`job definition` ]

**L** [ :term:`lxc` ]

**M** [ :term:`master` ] [ :term:`messageID` ] [ :term:`metadata` ]
[ :term:`MultiNode` ]

**O** [ :term:`offline` ]

**P** [ :term:`parameters` ] [ :term:`PDU` ] [ :term:`physical access` ]
[ :term:`pipeline` ] [ :term:`priority` ] [ :term:`production image` ]
[ :term:`prompts` ] [ :term:`protocol` ]

**Q** [ :term:`query` ]

**R** [ :term:`refactoring` ]
[ :term:`remote worker`]
[ :term:`restricted device` ]
[ :term:`results` ]
[ :term:`retired` ]
[ :term:`role` ] [ :term:`rootfs` ] [ :term:`rootfstype` ]

**S** [ :term:`scheduler` ]

**T** [ :term:`test run` ] [ :term:`test shell` ] [ :term:`tftp` ]

**V** [ :term:`VLANd` ]

**W** [ :term:`worker` ]

**Z** [ :term:`ZMQ` ]


.. glossary::

  action level
    The :term:`pipeline` is organised into sections and levels. The first
    section of the pipeline is given level 1. Sub tasks of that section start
    with level 1.1 and so on. Log files and job definitions will refer to
    actions using the level. Details of the action can then be accessed using
    the level as the location: ``job/8360/definition#2.4.5``

    .. seealso:: :ref:`pipeline_construction`

  alias
    A string which can be used to relate the descriptive device-type name to a
    particular list of aliases which could be used to lookup the matching
    device-type. This can be useful to list the :term:`device tree blobs <DTB>`
    which can be used with this device-type. (Aliases cannot be used in job
    submissions directly.) Multiple device-types are allowed to share the one
    or more aliases.

  chart
    A chart allows users to track :term:`results` over time using
    :term:`queries <query>`.

  ci loop
    Continous Integration (CI) typically involves repeated automated
    submissions using automated builds of the artifacts prompted by
    modifications made by developers. Providing feedback to the developers on
    whether the automated build passed or failed creates a loop. LAVA is
    designed as one component of a ci loop.

    .. seealso:: :ref:`ci_loop`, :ref:`continuous_integration` and
      :term:`metadata`

  device
    A device in LAVA is an instance of a :term:`device type`.

    * Test writers: see :term:`device tag`

    * Admins: see :ref:`create_device_database` and :term:`device dictionary`.

    * Developers: see :ref:`naming_conventions`

  device dictionary
    The device dictionary holds data which is specific to one device within a
    group of devices of the same device type. For example, the power control
    commands which reference a single port number. The dictionary itself is a
    key:value store within the LAVA server database which admins can modify to
    set configuration values according to the :term:`pipeline` design.

    .. seealso:: :ref:`create_device_dictionary` and
      :ref:`viewing_device_dictionary_content`.

  device owner
    A device owner has permission to change the status of a particular device
    and update the free text description of a device. Note that superusers of
    the LAVA instance are always able to submit jobs to and administer any
    devices on that instance.

    .. seealso:: :ref:`device_owner_help` and :ref:`owner_actions`.

  device status transition
    A record of when a device changed :ref:`device_status`, who caused the
    transition, when the transition took place as well as any message assigned
    to the transition. Individual transitions can be viewed in LAVA at
    ``<server>scheduler/transition/<ID>`` where the ID is a sequential integer.
    If the transition was caused by a job, this view will link to that job.

  device tag
    A tag is a device specific label which describes specific hardware
    capabilities of this specific device. Test jobs using tags will fail if no
    suitable devices exist matching the requested device tag or tags. Tags are
    typically used when only a proportion of the devices of the specified type
    have hardware support for a particular feature, possibly because those
    devices have peripheral hardware connected or enabled. A device tag can
    only be created or assigned to a particular device by a lab admin. When
    requesting tags, remember to include a description of what the tagged
    device can provide to a Test Job.

    .. seealso:: :ref:`device_tags_example`

  device type
    The common type of a number of devices in LAVA. The device type may have a
    :term:`health check` defined. Devices with the same device type will run
    the same health check at regular intervals. See :ref:`device_types`.

  developer image
    A build of Android which, when deployed to a device, means that the device
    **is visible** to ``adb``. Devices configured this way will be able to have
    the image replaced using any machine, just be connecting a suitable cable,
    so these images are not typically deployed onto hardware which will be sold
    to the customer without having this image replaced with a production image.

    .. seealso:: :ref:`lava_lxc_protocol_android`

  dispatcher
    A machine to which multiple devices are connected. The dispatcher has
    ``lava-dispatcher`` installed and passes the commands to the device and
    other processes involved in running the LAVA test. A dispatcher does not
    need to be at the same location as the server which runs the scheduler. The
    term ``dispatcher`` relates to how the machine operates the
    ``lava-dispatch`` process using ``lava-slave``. The related term
    :term:`worker` relates to how the machine appears from the :term:`master`.

  distributed deployment
    A method of installing LAVA involving a single :term:`master` and one or
{'fraction_non_alphanumeric': 0.1010867186930202, 'fraction_numerical': 0.0016045510903654001, 'mean_word_length': 3.769391304347826, 'pattern_counts': {'":': 0, '<': 11, '<?xml version=': 0, '>': 11, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 2, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '1158943', 'n_tokens_mistral': 3839, 'n_tokens_neox': 3718, 'n_words': 1745}