JoelSpeed
commented
2 weeks ago Schema checker also has ideas about being an admission hook, but we haven't got that far yet.
Does it make sense to combine those two initiatives into a single one and share the checking library perhaps?
Yes, I think it does. We also have plans to discuss with SIG-APIMachinery upstream about the idea of making this an upstream project, and potentially even introducing the idea as a feature in the CRD server within Kube directly.
At the moment though, this project is somewhat volunteer led as and when we have the time to, so, gathering more help and maintainers for the core parts would be helpful.
I think probably the best step for us is to start trying to move this project upstream into something Kube owned and then integrating from there?
Do you have a link to where the equivalent functionality has been implemented in OLM?
pgodowski
As part of Operator Lifecycle Manager v1 (OLM-v1) project, there is introdued CRD upgrade preflight checking, which conceptually has same/similar goals as crd-schema-checker project.
Differences being that crd-schema-checker is positioned currently more like a stand-alone CLI to run as part of the build pipeline, whereas OLMv1 would check CRD compatibility at runtime (i.e. when ClusterExtensions are deployed), yet still, there is a common piece of logic which attempts to detect the incompatible changes being made by the CRD owners.
Does it make sense to combine those two initiatives into a single one and share the checking library perhaps?
Also opened ticket in OLMv1 to discuss the same: https://github.com/operator-framework/operator-controller/issues/1384
@JoelSpeed