Architecture Design Records¶
During the development of crinit, many decisions have to be made. This chapter provides a place to collect new ideas and discuss them until we are able to agree on a final decision of an topic.
An Architecture Design Record (ADR) should follow roughly the pattern
Problem Description
Influencing factors
Assumptions
Considered Alternatives
- Decision
Rationale
Open Points
There is an ADR template which can be used as a starting point.
List of ADRs¶
Contents:
- ADR Template
- Design Decisions - Choice of helper library to impelement the capability feature
- Design Decisions - Choice of how crinit’s default capabilities are merged into a task’s capability set
- Architecture Design Record - Choice of cryptographic library for config signatures
- Architecture Design Record - Management of named pipes for IO redirection
- Architecture Design Record - Storage scheme for public keys
- ADR crinit as secondary init
- Architecture Design Record - Choice of signature algorithm for signed configurations
- Architecture Design Record - Configuration interface for signature handling
- Architecture Design Record - Storage scheme for file signatures
- Architecture Design Record - INCLUDE file options
- Design Decisions - Do we want to support hierarchical cgroups?
- Design Decisions - How to handle an invalid cgroup configuration
- Design Decisions - Cgroup management
- Design Decisions - Where to define cgroups?
- Design Decisions - One cgroup per unconfigured task or a common cgroup for all unconfigured tasks
- Design Decisions - Should the crinit process itself be placed in a cgroup on its own?
