Worker Model

Purpose

The goal of CDS is to start a worker when you need it, which should match all your requirements exactly. In order to scale automatically on demand, it is possible to register a worker model.

The goal of a worker model is to describe the capabilities of a given Docker/ISO image in terms of architecture, pre-installed binaries or libraries.

Types

There are 4 types of worker models:

• Docker images, see how to create a worker model Docker
• OpenStack images, see how to create a worker model OpenStack
• vSphere images, see how to create a worker model vSphere
• Host worker model, which means workers launched on the same host as the hatchery. The security implication of such setup is lack of isolation between worker processes. They will share host resources like CPU, RAM, file system etc. For this reason, we don’t recommend using this model in production.

Behavior

All registered CDS hatcheries start/kill workers as needed.

Add a worker model

A user can add a worker model by setting an owner group if user is administrator of group.

A CDS administrator can add a worker model, a worker model pattern and attach it to ‘shared.infra’ group.

What’s a worker model pattern?

A pattern of scripts configuration of CDS workers that CDS administrator create to let users use this pattern when they want to create a worker model. For more information click here.

What’s a restricted worker model?

A shared.infra hatchery can launch all worker models, except ‘restricted’ worker models.

Use case: users can launch their own hatchery. To use their worker models only with their hatchery, they have to set worker model as ‘restricted’.