pollypkg / polly Goto Github PK

The initial pass at datafaces defines them as lists of signals, then declares the world's simplest possible definitions of RED and USE. This immediately leads to two related questions:

• Who gets to define a dataface?
• How does a polly package refer to a dataface when implementing it?

The initial pass allows polly itself to define datafaces, but polly packages can't really do so - they can only implement them. This is a bit like only allowing the standard library of a programming language to define interfaces, and clearly has to change.

But, limiting dataface references to only those defined by the "stdlib" has the advantage of making imports quite simple - we can restrict to only importing github.com/pollypkg/polly/schema, and then a pop can just reference the dataface definitions directly (e.g. pollyschema.USE, here)

Need a viable approach here that:

• Allows datafaces to be defined outside polly itself/stdlib
• Keeps references sane, ideally without needing to rely directly on CUE package management for arbitrary packages

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.

Currently, signals are defined in PollyPackage as a list, for the reasons in the comment:

Addressing list elements in CUE is just...super annoying. I already wrestled with it months ago with scuemata. It may get better, but i don't want to wait, and the justification in the comment is flimsy at best. So, better to use a map structure.

We should have a GH pages-based docs site with examples etc. I suggest using mkdocs and offer to set up things incl. publishing automation.

• https://groups.google.com/g/mixins/c/q8B-nWgfO24
  • found on page https://pollypkg.github.io/polly/about/
• https://pollypkg.github.io/lifecycle/
  • found on page https://pollypkg.github.io/polly/
• https://pollypkg.github.io/vision/
  • found on page https://pollypkg.github.io/polly/
• https://pollypkg.github.io/contrib/
  • found on page found on page https://pollypkg.github.io/polly/

Starting with the Go CUE SDK is pretty intimidating. I've done it a few times already. To help bridge that gap for others/start bridging the gap between polly and other existing toolchains, i'll make a very simple library for interacting with pops, and a corresponding CLI that will validate a pop against the PollyPackage schema.

First pass at it is gonna be really, really sloppy. Lots of fodder for issues and requests for improvement :)

The docs site doesn't provide links to the meeting notes, community calendar, etc., which is hindering organic discovery and participation difficult. Let's fix that!

#22 proposes the creation of a simple CLI tool which can validate a pop.

It would also likely be worth having a subcommand to strip out certain values - e.g., id, gnetId - that are known to be non-portable, and thus inappropriate for use in a pop.

I believe it would help with adoption in new projects if we could somehow import existing jsonnet mixins as a polly pkg.

I hit this issue when rewriting parts of kube-prometheus into cue as all upstream monitoring mixins are written in jsonnet.

To get to the point where we can make minimal use of polly, we absolutely have to have sufficiently mature schema for all of our key object types. Prometheus is good enough - thankfully, rules and alerts aren't complicated - but Grafana dashboards are, of course, the hard one.

We're pushing hard on getting this done (now that everyone's back from summertime vacations). Issue to track it is here: grafana/grafana#36844

While playing around with converting node_exporter mixin to pollypkg I found a limitation of the current polly alerts schema - there cannot be a duplicate alert with different severity.

For example, node_exporter mixin is shipping 2 alerts named NodeFilesystemSpaceFillingUp with different expressions and severities. It's useful to have them share names when we consider how inhibition rule can be written for such alerts (example in kube-prometheus)

Am I missing something, or current schema makes it mandatory to have unique alert names?

Repo needs a code of conduct.

On our project website we should have an About entry, introducing folks and companies behind this initiative.

@mhausenblas suggested that the docs site would benefit from having some standard docs explaining the examples we create. An excellent idea! Creating this issue for him as a TODO to write up such guidelines :)