Architecture Design Records¶
During the development of elos, 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 * Rational * Open Points
There is an ADR-Template Design Decisions - which can be started with.
List of ADRs¶
Contents:
- Design Decisions -
- Architecture Design Record - Atomic Variables
- Architecture Design Record - Detecting Coredumps
- Architecture Design Record - elos event logging concept DRAFT
- Architecture Design Record - Evaluation Of Logging Frameworks
- Architecture Design Record - Event publishing authorization
- Architecture Design Record - Blacklist filtering of published events
- Architecture Design Record - Event Storage
- Architecture Design Record - Event Retention Policy
- Architecture Design Record - Event Storage Backend
- Architecture Design Record - Event Storage Class
- Architecture Design Record - Event Throtteling
- ADR - Feature set of elos “fetch” DRAFT
- Handle kernel module dependencies for Elos
- Out of memory process killer
- Evaluation of the gitlab package registry, with regards to storing and using the elos subproject debian packages.
- Architecture Design Record - Shared Memory Locking
- Design Decisions - Enforce usage of _FORTIFY_SOURCE
- Design Decision – communication protocol
- Architecture Design Record - libelos logger concept
- API concept to use elos with a C++ interface
- 1) Connect in constructor vs connect is used in each API function
- 1.1) Connect in constructor
- 1.2) connect is used in each API function
- 2) user autonomy vs subscription management
- 2.1) user autonomy
- 2.2) subscription management
