OpenSLO/oslo

Unify schema validation with OpenSLO Schema

Opened this issue · 2 comments

nieomylnieja commented

Problem to solve

Right now oslo validate relies on govalidator and it's struct level annotations to run the validation of the selected specs.
This means we're maintaining the OpenSLO spec rules both inside oslo and in the main OpenSLO repo.
I propose to get rid of that dualism and rely entirely on JSON Schema defined here.
There's a native Go library which implements JSON Schema called gojsonschema, which we can use to run the validation for oslo validate.

Proposal

Use a tool like https://github.com/xeipuuv/gojsonschema to validate the spec and get rid of govalidator entirely.

kenfinnigan commented

This ties into: OpenSLO/OpenSLO#113 OpenSLO/OpenSLO#20 OpenSLO/OpenSLO#87 #100

OpenSLO/OpenSLO#124 is the main issue on this topic

The main issue at present is there is no agreement on what the "single source of truth" for the specification is within OpenSLO. Though there was initial work to create the JSON schema, it hasn't been updated in 5 months, where as the specification defined in the README has been updated.

nieomylnieja commented

sorry for the (very) late response @kenfinnigan
I understand we're still lacking consensus on where to move further on, maybe we could discuss that on one of the upcoming community meetings?

The problem I now see with JSON schema and embedding it in oslo via sth like gojsonchema is that the library is not maintained anymore, same goes for this one, and these are the only established options on the market right now. While forking is an option if issues arise, I wouldn't want us getting tied down with unmaintained libraries.

I kinda like the idea with cue though, I think it provides more language agnosticism and richer ecosystem for conversion to language specific validators and open source specifications. It also has first class support for Go, as it is written in it.

Going with plain Go structs will give us the most freedom in oslo, but that's about it I'm afraid, and I don't think convenience in building a single tool should influence the final choice much anyway.