Query parsers in polly/cue

[sdboyer]

If we're treating queries as a first-class concept in polly by way of signals, then it begs an obvious question - can we analyze and validate those queries directly in CUE? That is, write e.g. a PromQL parser in CUE. My computability theory is too weak to know if this is possible or not.

It seems likely this would be far too much effort/the risks arising from two parsers, but if such a parser were to exist, the value would be in not only validating that a query string is valid for the language, but about more specific properties of the query. Most obvious - it could be used to produce type information about the query return, which is a key goal anyway (another discussion item coming about this soon).

For example, @brancz and i have discussed that it's almost only ever label matchers that we want to be parameterizable. If PromQL queries could be parsed into a structure (and CUE variable interpolations retained through the parsing), it should then be straightforward to actually write a constraint, in CUE, guaranteeing that promql signals have variable interpolations on their label matchers.

That could be enforced in polly itself (probably unwise?), or provided as an optional policy that organizations consuming polly packages could choose to apply themselves. And, of course, orgs could trivially write their own policies, analogous to what Cloudflare has done with pint.

[metalmatze]

This idea was originally brought forward to be directly added to Prometheus. It might be way better suited here anyway.
Here's the original discussion: prometheus/prometheus#7197

[brancz]

I don't see an issue with having it be a feature of the parser, and not expose it to Prometheus users directly in the UI. Happy to discuss this again in an upcoming dev summit or out of band.

[sdboyer]

@brancz glad you're still interested in revisiting! Though i'm curious about your take on the original base premise of the discussion - having another promql parser written directly in CUE, that produces CUE datastructures

[brancz]

I would try to avoid the duplication, but I can't say I haven't dabbled with the idea of doing it in jsonnet, so I guess if we can't get it into the canonical parser, then that would be the next best thing I think.

[sdboyer]

The drawback to having it in the canonical parser - from polly's perspective - is that those structures won't be directly accessible in polly itself, which effectively negates the user's ability to express constraints/directly target them. This is what's warming me more and more to this - to @beorn7's comment that "you have to understand the entire AST to make use of it," idk how useful exposing such things is in the general case, but i do feel pretty confident that polly's providing a more bounded context in which we actually can reason about what people might want to do with it/that we're targeting a more limited audience.

Caveat: it may be possible to expose the Go parser function directly into CUE-space, which might allow us to define a structure in CUE, but do the actual parsing work using the canonical parser. That might be the best of both worlds, though from CUE's perspective, defining "custom" Go functions can have implications for CUE's package management that i don't yet fully understand, beyond knowing that it could make certain uses of the CUE Go API awkward.

[brancz]

The later paragraph is vaguely how I envisioned it to work as well.

[sdboyer]

Curious about your thoughts on this @beorn7, especially given this thoughtful comment: prometheus/prometheus#7197 (comment)

[beorn7]

Yeah, it feels weird to read those thoughtful comments the past-me made. I guess I haven't thought about this in a while.

Does it help that the Go parser is generated these days? Could a CUE parser be generated in the same way from the same Yacc sources? Is the PromQL LSP implementation of any help (as inspiration or to be used directly)? See https://github.com/prometheus-community/promql-langserver

[sdboyer]

Generating from the same Yacc sources would definitely alleviate the duplication concern, that's suuuper good to know. That said, i'm really out of my depth at the level of parser generators, so i'll have to ask around when it comes to generating CUE from Yacc. That'll also extend to the issues you raised about needing a sublanguage for types (naively, i would imagine CUE's type system should be sufficient?).

I suspect i'm gonna have to put this one down in favor of other things i more directly know how to make progress on.

[brancz]

I think that's probably a reasonable choice, even though it would have been very nice to have and Tom and I played with the idea of the jsonnet PromQL parser, it didn't prevent us from creating useful things with it.