This repository was archived by the owner on Nov 2, 2024. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 147
Setup folder structure to store artifact configurations #1037
Copy link
Copy link
Open
Labels
priority: p3Desirable enhancement or fix. May not be included in next release.Desirable enhancement or fix. May not be included in next release.type: processA process-related concern. May include testing, release, or the like.A process-related concern. May include testing, release, or the like.
Milestone
Description
Description
All Configurations are stored under /configurations folder at the root of the repo. Each Configuration is stored in a dedicated folder. The name of the folder is used as ID of the configuration. The name is validated by regex ^[a-zA-Z_][a-z-A-Z0-9_\-]+$ (letters, numbers, underscore and dash, starting with a letter or underscore with the length greater than 1).
Inside each Configuration the parameters are stored in multiple files per artifact functionality:
- alerts.yaml -- alert policies and notification channels
- dashboards.yaml -- custom monitoring dashboards
- healthchecks.yaml -- health check definitions
- metrics.yaml -- custom log-based metric definitions
- services.yaml -- custom monitoring service definitions
- slos.yaml -- monitored service SLOs including custom and auto-recognized services
Additionally, the folder will has a recipe subfolder /configurations/{ID}/recipes to store o11y recipes (see #1028)
Schemas for these YAML files will be stored in the /provisioning/schemas/configuration folder.
Describe alternatives you've considered
The following options were considered:
- each Configuration is stored in a single file that describes ALL artifacts
pros simple to transfer and host
cons hard to manage or even understand because the file will be too big - use index file to describe a Configuration; artifacts can be referenced as independent files stored anywhere
pros flexible storage options
pros allows artifact parameters across multiple files (e.g. two files to store service SLOs)
pros allows reuse configurations
cons hard to host and transfer; increases chances to cause unexpected problems when modifying a file referenced in more than one Configuration
cons hard to manage or even understand because the files can be distributed and parameters can conflict
Additional context
It is a sub-issue for #1026.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
priority: p3Desirable enhancement or fix. May not be included in next release.Desirable enhancement or fix. May not be included in next release.type: processA process-related concern. May include testing, release, or the like.A process-related concern. May include testing, release, or the like.