Depends on #283

This issue might be of interest to these efforts: #18

I've closed the previous issue on that: #87, but you might still find Ken's comments of value and relevance.

Is the goal of OpenSLO to provide full, generated Kubernetes CRDs and enable usage purely as a library by Kubernetes Operators, or should usage look something like this: https://github.com/oskoperator/osko/pull/129/files#diff-c0681b1695b5f75b8093dc4fa7177e2d46bcc28236759831f84b582670fe2916R23 where the Kubernetes operator is still responsible for the fields mainly related to k8s and just uses the pure spec of OpenSLO?

@nieomylnieja thoughts on this?

@fourstepper Imo we should have generated objects of Kind CustomResourceDefinition so probably your first option.

Not everyone have to use kubebuilder as their tool for building an operators and not all of them have to be written in go. Providing CRDs is more flexible and open solution.

I generally do agree with that, although it brings some more responsibility/maintenance to this repository (which however I think we agreed on before, though). I will continue with that in mind :)

Note to self: Make sure that the CI checks that the CRDs have been generated to reflect latest changes in the code (aka probably by doing the generation in CI and checking if git sees no changes)