Module update

Each module retrieves its own configuration during its boot sequence. This configuration is immutable throughout the life cycle of the module. This means that for each new configuration, the module is stopped and restarted. During the boot sequence, the module fetches the new configuration.

Default

When a new configuration is available, osp-configuration-dispatcher will send a restart request via the messaging service. When the module receives the message, it will complete its tasks and stop itself.

Swarm orchestration will detect that there are no modules running for a particular service (via healthcheck) and automatically create a new one.

Parallel

This update design aims to minimise downtime during the update process. The osp-configuration-dispatcher uses the Docker api to create a rolling update request. The responsibility for updating the module is then delegated to the swarm. The update process now depends on the service configuration (file module.service).

By default, this update design use the following configuration:

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

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

Warning

This update design is dependent on Swarm orchestration. This requirement denied use with remote modules (running without orchestration).