Feature: Support OpenAPI reflection

[dilyevsky]

I'm working on a prototype to have OpenaAPI types reflected in Starlark (e.g use case - #70). Rough API I'm shooting for:

monitoring = openapi("monitoring.coreos.com/v1")

def main(ctx):
    return monitoring.PrometheusRule(
        metadata = ...,
        spec = monitoring.PrometheusRuleSpec(
            ...
        ),
    )

...so it's very similar to proto types but separate registry and reflection is based on OpenAPI v2/3 schema definitions.

I could package this in a separate library but skycfg seems like a logical place for it considering above so opening this to gauge interest, etc

+cc @jmillikin-stripe

[jmillikin-stripe]

This seems like it'd be difficult to reconcile with skycfg's goals of being hermetic and deterministic, since the behavior would now depend on dynamically fetching API specifications.

Maybe it'd be possible to define a mapping from OpenAPI to Protobuf? Then that could be combined with the new dynamic reflection capabilities in go-protobuf master.

[dilyevsky]

This seems like it'd be difficult to reconcile with skycfg's goals of being hermetic and deterministic, since the behavior would now depend on dynamically fetching API specifications.

In my prototype I'm letting the library user decide on that by requiring SpecProvider interface which just returns OpenAPI doc by string key. Fwiw you can already do similar non-hermetic type injection with existing proto registry interface 🤷

Maybe it'd be possible to define a mapping from OpenAPI to Protobuf? Then that could be combined with the new dynamic reflection capabilities in go-protobuf master.

Yeah I've thought about adopting similar approach and there are even some libraries one can re-use to do this (at least for v1 google/protobuf api) but it seems like that would be equivalent of just compiling Open API schema into binary as an embedded asset via https://github.com/markbates/pkger or similar).

[dilyevsky]

Then that could be combined with the new dynamic reflection capabilities in go-protobuf master.

So I was looking more deeply into this option and this should work so my next question is what is github.com/golang/protobuf v2 API migration plan? 😄

I'd imagine Skycfg will need to support both v1 and v2 reflection for some time? I can start kicking some tires on that if you haven't already (should probably open separate issue for that).