Design Decisions - Where to define cgroups?

Problem

If we decide to handle cgroups natively in crinit we have to decide where cgroups can be defined.

Influencing factors

The following constraints have to be taken into account for a suitable solution:

  • Respect the capabilities of Crinit config files. (Key/Value-Pairs and lists)

Assumptions

The following assumptions have been made in the decision process:

Considered Alternatives

1) In series file only

Cgroups can only be defined and created in the series file part of the configuration.

pros

  • All cgroups are defined in one place.

  • All cgroups are created before they are used

  • If multiple tasks use the same cgroup this approach is the more natural one to use a shared ressource in multiple places.

cons

  • If a single task want its own very specific cgroup it has to relay on a proper modified series file.

  • Increase complexity of configuration parser, considering the nature of crinit series files the cgroup identifier and properties assignments must be somehow encode in the key/value pairs.

2) In task files only

Cgroups can only be defined and created in task files.

pros

  • Every task creates the cgroups that it needs. This would allow for a nice atomic approach.

  • Easy to map the additional options to new config options (key/value pairs) cons

  • If multiple tasks need to use the same cgroup they would have to wait on a setup task or other tasks to which they share no further mutuality.

  • Probably not intuitive and error prone, leading to the question “which task file create is creating this cgroup?”

3) Allow cgroup definition in series and task files

Cgroups can be defined and created in series and task files.

pros

  • Commonly used cgroups can be defined in a common place

  • Tasks don’t need to wait for otherwise unrelated tasks.

  • Tasks can create their own cgroups that are only relevant for themselves.

cons

  • It’s the most complex approach.

4) In separate cgroup configuration files

A completely separate configuration file structure is introduced. Under the crinit sysconfig directory there could be a sub-directory where *.crinit-cg files are stored that contain the cgroup configuration.

pros

  • The cgroup initialization is a separate phase in the crinit startup before and unrelated to task loading.

  • The parser is less complicated as the naming of cgroups is done through the file system and doesn’t need to be merged somehow into the configurations keywords or values.

cons

  • A separate parser is needed

  • The configuration of task-specific cgroups gets unintuitive

  • A format for those configuration files has to be defined

Decision

Alternative 3 is taken.

Rationale

Open Points

if something was left open after this decision