osp-configuration-dispatcher

Overview

The configuration dispatcher functions as a repository storing configurations and facilitating access to other modules. It maintains a configuration history, enabling review of changes and the ability to revert to prior configurations.

This module offers the following functionalities:

  • Authentication of modules

    • Generation of module certificates when required.

    • Storage of certificates in Swarm.

    • Maintenance of up-to-date stack definitions based on the configuration.

  • Storage of configuration (refer to the persistent configuration section for details).

  • Sending of configuration to modules.

  • A GIT interface with validation of the configuration

Warning

During its initial execution, the dispatcher may experience delays in certificate generation. These delays can become particularly pronounced in cases where the system lacks a reliable entropy source, such as in virtual machine environments. It is essential to ensure that your system is properly configured for optimal performances in such situations.

List of configuration files

Filename

Short description

Format

Documentation

module.service

Each service is described in its proper file and then assembled

yml

See the Swarm administration or Official documentation

module.dispatcher

Defines the dispatcher configuration

json

module.dispatcher

Healthcheck

The process survey that the GIT hook is available.

Environnement variables

Note

Environnement variables can be used to fine tune some of the module parameters, for generic information see the swarm page.

Variable name

Default value

Usage

DISPATCHER_HOST

10000

The hostname on which the modules can fetch the configuration

DISPATCHER_PORT

Describe the SWARM configuration see below

The port on which the modules can fetch the configuration

dispatcher-threads-number

50

The configuration dispatcher’s thread count can be adjusted, especially when dealing with a high number of modules. This adjustment is particularly useful as the dispatcher dedicates one thread to each module during the configuration parsing process. If you’re working with constrained CPU resources, reducing this value can be beneficial.

dispatcher-threads-file-hierarchy

50

This is the number of virtual threads used for the initial step of configuration parsing. The number of threads represents a trade-off between synchronization time and concurrent performance improvement. Since these are virtual threads, there is no strict limit on the number of threads that can be used.

aggregation-timeout-ms

15000

The maximum time in millisecond to parse the configuration when a new one is pushed. After this timeout the configuration is rejected.

wait-for-configuration-timeout-ms

60000

The maximum time to wait for another configuration to be fully parsed