Setup folder structure to store artifact configurations

[minherz]

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.

[NimJay]

Commenting since this is in our team's out-of-SLO bucket:

• @minherz
  • First off: thank you for the super clear issue description!
  • Question: is this an issue we should close now that Cloud Ops Sandbox might go into a strict "maintenance only" state (in the near future)?

[minherz]

@NimJay I depreoritized it to p3. However, I prefer to keep all relevant issues opened until we decide on the roadmap of the project. Once it is decided I will go to update the milestones and change the issues accordingly.