Create Custom Resource Definitions (CRDs) to represent the spec

[kenfinnigan]

Problem to solve

At the moment there is YAML within the README defining the desired structure, and it appears the specification is embedded into https://github.com/OpenSLO/oslo

Making it difficult to grab the specification and utilize it.

Proposal

To align with the Kubernetes ecosystem, it would be great if there were CRDs that defined the various parts of the specification.

Links / references

https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/

[embano1]

Related #20

[kenfinnigan]

I'm going to start looking at this and was curious as to the preferred approach, as we have a few available possibilities.

From my perspective I see the following goals:

• OpenSLO specification CRD for use with Kubernetes
• Schema for OpenSLO specification that can be used for basic validation processing. i.e. used by Oslo
• Go Structs for OpenSLO specification components aligned with the Schema (I know there are structs in Oslo at present, but it would be good to have the Struct and Spec in the same repository for alignment)

In terms of how we get there, here are the options I'm aware of:

1. Define a schema with Cue as per WIP: Define schema with cue #32. It appears possible to generate a Kubernetes CRD from Cue, but I couldn't see a way to generate Go structs from it. Looks like there is a way to generate validation methods for Go, but it didn't really explain if it was backed by a Struct or not. If anyone has details, please share.
2. Define a Go Struct for the OpenSLO specification components (maybe using the existing Oslo ones as a starting point) and use the Kubernetes code generator to generate a CRD from the Go Structs. The generation could be tied into the build/release process to prevent PRs needing to run the CRD generation process for each change.

I don't have a preference as to the process, but I'd appreciate feedback from the community as to the preferred approach.

Should I be proposing a PR based on option 2, or looking to help with #32 for option 1?