Skip to content
This repository was archived by the owner on Nov 2, 2024. It is now read-only.

Setup folder structure to store artifact configurations #1037

@minherz

Description

@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.

Metadata

Metadata

Assignees

Labels

priority: p3Desirable enhancement or fix. May not be included in next release.type: processA process-related concern. May include testing, release, or the like.

Type

No type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions