Module update

Each module retrieves its configuration only once, during its boot sequence. This design choice ensures a more secure runtime environment, as the configuration remains immutable throughout the module’s lifecycle. Any configuration change therefore requires stopping and restarting the module.

The main drawback of this approach is the downtime incurred during module updates. However, this can be mitigated by using parallel updates managed by the orchestrator. In this case, a new instance is started and validated before the previous one is stopped. Since most modules start very quickly, parallel updates are only applied to modules with heavier configurations (such as web modules). The list of modules and their corresponding update method is provided in the Update Mode column of this page Modules capabilities

Default

When a new configuration becomes available, the osp-configuration-dispatcher sends a restart request through the messaging service. Upon receiving this message, the module completes its tasks and shuts down. Swarm orchestration then detects the absence of running modules for the given service (using healthcheck) and automatically starts a new one.

Parallel

Warning

The feature is only supported for LOCAL module, remote module automatically fallback to default mode

The system requests the osp-configuration-dispatcher to be restarted (see Environment Variables to customize these values). If the restart fails and the dispatcher is not successfully restarted, it will terminate itself as in the default mode.

Depending of the orchestrator used the logic will be different, see chapter below

Swarm

This update mechanism is designed to minimize downtime during the process. The osp-configuration-dispatcher leverages the Docker API to initiate a rolling update request. The responsibility for updating the module is then delegated to the Swarm. The update process depends on the service configuration defined in the Modify the configuration of a service file.

By default, this update design use the following configuration:

deploy:
  update_config:
    parallelism: 1
    delay: 0s
    order: start-first

The orchestrator will create a new module and wait for a valid health check. When the new module is ready, the oldest will be stopped.