Skip to content

Commit

Permalink
feat: init kube monitoring labels adr
Browse files Browse the repository at this point in the history
  • Loading branch information
IvoGoman committed Jul 25, 2024
1 parent daf781e commit 9807378
Showing 1 changed file with 86 additions and 0 deletions.
86 changes: 86 additions & 0 deletions architecture-decision-records/012-greenhouse-label-conventions.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,86 @@
# 012-greenhouse-label-conventions

- Status: [draft] <!-- optional -->
- Deciders: [Richard, Esther, Arno, Akshay, David R.] <!-- optional -->
- Date: [YYYY-MM-DD when the decision was last updated] <!-- optional. To customize the ordering without relying on Git creation dates and filenames -->
- Tags: [greenhouse / cloudoperators] <!-- optional -->
- Technical Story: [description | ticket/issue URL] <!-- optional -->

## Context and Problem Statement

Define which functionalities rely on labels and which labels these are. This should be done for the entire stack (e.g. Metrics, Logs, Alerts, Playbooks, Plutono, UIs[Supernova, ...] ...)
This also includes indentifying mandatory labels (e.g. owner-info etc.), which are used for alert routing...

The goal of this ADR is to define a common set of labels that can be used across all components of the greenhouse stack. These labels should then also be enforced, defaulted and integrated across Greenhouse.

## Decision Drivers <!-- optional -->

- [driver 1, e.g., a force, facing concern, …]
- [driver 2, e.g., a force, facing concern, …]
-<!-- numbers of drivers can vary -->

## Considered Options

- [option 1]
- [option 2]
- [option 3]
-<!-- numbers of options can vary -->

## Decision Outcome

Chosen option: "[option 1]",
because [justification. e.g., only option, which meets k.o. criterion decision driver | which resolves force force | … | comes out best (see below)].

### Positive Consequences <!-- optional -->

- [e.g., improvement of quality attribute satisfaction, follow-up decisions required, …]
-

### Negative Consequences <!-- optional -->

- [e.g., compromising quality attribute, follow-up decisions required, …]
-

## Pros and Cons of the Options | Evaluation of options <!-- optional -->

### [option 1]

[example | description | pointer to more information | …] <!-- optional -->

| Decision Driver | Rating | Reason |
|---------------------|--------|-------------------------------|
| [decision driver a] | +++ | Good, because [argument a] | |
| [decision driver b] | --- | Good, because [argument b] |
| [decision driver c] | -- | Bad, because [argument c] |
| [decision driver d] | o | Neutral, because [argument d] |

### [option 2]

[example | description | pointer to more information | …] <!-- optional -->

| Decision Driver | Rating | Reason |
|---------------------|--------|-------------------------------|
| [decision driver a] | +++ | Good, because [argument a] | |
| [decision driver b] | --- | Good, because [argument b] |
| [decision driver c] | -- | Bad, because [argument c] |
| [decision driver d] | o | Neutral, because [argument d] |

### [option 3]

[example | description | pointer to more information | …] <!-- optional -->

| Decision Driver | Rating | Reason |
|---------------------|--------|-------------------------------|
| [decision driver a] | +++ | Good, because [argument a] | |
| [decision driver b] | --- | Good, because [argument b] |
| [decision driver c] | -- | Bad, because [argument c] |
| [decision driver d] | o | Neutral, because [argument d] |

## Related Decision Records <!-- optional -->

[previous decision record, e.g., an ADR, which is solved by this one | next decision record, e.g., an ADR, which solves this one | … | pointer to more information]

## Links <!-- optional -->

- [Link type](link to adr) <!-- example: Refined by [xxx](yyyymmdd-xxx.md) -->
-<!-- numbers of links can vary -->

0 comments on commit 9807378

Please sign in to comment.