We need scuemata definitions for Prometheus alerts and rules.
The most sensible place to put them, for now, is cue.mod/pkg/github.com/prometheus/prometheus. Once everything's properly up and running with Polly, we'll expect the scuemata definitions for upstream objects to live outside of the Polly repo. We're making an exception here because a) parity with mixins, and b) we're bootstrapping, and it's not reasonable to expect Prometheus to just take this on without us having demonstrated utility first.
Defining these objects is going to be a bit interesting. Existing mixins follow pretty directly on the structure of rules/alerts themselves - a name, with an array of individual objects. They're defined as collections, rather than individual objects. And i'm reasonably certain that what we want to scuematize is the individual object, and treat the grouping of them as a separate concern. And, wherever we deal with that concern - which i suspect will be in how we define them within PollyPackage - we absolutely want to use a map structure, rather than a list structure, to make addressing and manipulating them easier by consumers.
We need scuemata definitions for Prometheus alerts and rules.
The most sensible place to put them, for now, is
cue.mod/pkg/github.com/prometheus/prometheus. Once everything's properly up and running with Polly, we'll expect the scuemata definitions for upstream objects to live outside of the Polly repo. We're making an exception here because a) parity with mixins, and b) we're bootstrapping, and it's not reasonable to expect Prometheus to just take this on without us having demonstrated utility first.Defining these objects is going to be a bit interesting. Existing mixins follow pretty directly on the structure of rules/alerts themselves - a name, with an array of individual objects. They're defined as collections, rather than individual objects. And i'm reasonably certain that what we want to scuematize is the individual object, and treat the grouping of them as a separate concern. And, wherever we deal with that concern - which i suspect will be in how we define them within
PollyPackage- we absolutely want to use a map structure, rather than a list structure, to make addressing and manipulating them easier by consumers.