# Design Decisions - Do we want to support hierarchical cgroups?

## Problem

Cgroups can be organized in some sort of tree. If so, they can "inherit" some specifications from their parents. The inheritance process is described here: https://docs.kernel.org/admin-guide/cgroup-v2.html#top-down-constraint. It is no inheritance like e.g. a C++ programmer would expect it.
It seems that the way the resources are restricted or distributed is depending on the kind of resource. See here for more details: https://docs.kernel.org/admin-guide/cgroup-v2.html#resource-distribution-models

## Influencing factors

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

* New tasks can be added during runtime, hence it is possible that also a new
  cgroup is added during runtime. As processes can only be assigned to
  cgroup-leafs, adding new cgroups and processes down in the hierarchy can lead
  to complex cgroup/process reassignment tasks.



## Assumptions

The following assumptions have been made in the decision process:
* cgroups are created on startup
* cgroups can be created on runtime
* cgroups never disappear without restart




## Considered Alternatives

### 1) Don't support hierarchical cgroups

Don't support hierarchical cgroups.

*pros*
* Reduces complexity in the parser and the implementation in crinit
* Easy to add new cgroups on runtime

*cons*
* Maybe not capable to support complex scenarios or only very cumbersome. So the user would be restricted in some scenarios.


### 2) Support hierarchical cgroups

Support hierarchical cgroups.

*pros*
* Most flexible approach

*cons*
* More room for errors. Processes may only be in the leave nodes of the cgroup tree, for example.
* Complex to deal with new cgroups on runtime

## Decision

Decision 1 "Don't support hierarchical cgroups" is taken

### Rationale

The original ADR requests a "flat style". It states the following pros and cons:

*pros*
* integrator just needs to define cg/ns features he/she wants.
    But only meaningful selected ones.

*cons*
* feature bloat of crinit?

### Open Points

None.