search

operator-framework / enhancements

Apache License 2.0
9 stars 40 forks source link

Custom operator validation #43

Closed exdx closed 2 years ago

shawn-hurley commented 4 years ago

I just looked over the proposal and the first thing that I think we need to talk about is relying on pre 1.0 changing specification as the basis for an API we will have to support for an extended period of time.

What is the value of using cue and why is that a specific goal of the proposal to use this technology?

exdx commented 4 years ago

I just looked over the proposal and the first thing that I think we need to talk about is relying on pre 1.0 changing specification as the basis for an API we will have to support for an extended period of time.

What is the value of using cue and why is that a specific goal of the proposal to use this technology?

Using cue came directly out of the prior version of this enhancement (see #28) where we looked at all the possibilities of adding drop-in validation rules via flat files and came to this approach. cue formatted files make it easy to understand the validation rules and add new ones, which is a key requirement for this enhancement.

As I mentioned in the caveats, it is pre-1.0 API, and has not been used in OLM before. There is also the open question of whether using cue in the way that we would need to, as a library instead of a CLI tool, will end up working effectively, as this is undocumented and could potentially lead to undefined behavior.

It seems like we need a clear go/no-go on using cue to make progress on this enhancement. I'm looking at some alternatives in https://learnk8s.io/validating-kubernetes-yaml. For example the OPA-based conftest is similar, but also pre-1.0.

exdx commented 4 years ago

I updated the enhancement based on our conversation, and moved the status back to provisional for the time being, as this PR will remain open as we continue to look into this problem space.