search

OpenSLO / oslo

CLI tool for the OpenSLO spec
Apache License 2.0
201 stars 35 forks source link

Unify schema validation with OpenSLO Schema #214

Open nieomylnieja opened 1 year ago

nieomylnieja commented 1 year ago

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 1 year ago

This ties into: https://github.com/OpenSLO/OpenSLO/pull/113 https://github.com/OpenSLO/OpenSLO/issues/20 https://github.com/OpenSLO/OpenSLO/issues/87 https://github.com/OpenSLO/oslo/pull/100

https://github.com/OpenSLO/OpenSLO/issues/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 1 year ago

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.