-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Synergy with OLMv1 CRD upgrade preflight validation? #33
Comments
Schema checker also has ideas about being an admission hook, but we haven't got that far yet.
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? |
Take a look here: https://github.com/operator-framework/operator-controller/tree/main/internal/rukpak/preflights/crdupgradesafety |
Looks like there's some overlap between what we have implemented, and what's implemented there in kapp, but also some areas where we are disjoint. Would definitely be good to get some alignment before either of us go to far in adding more. I'll try and get some time to talk to the api machinery folks in their next call. |
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: operator-framework/operator-controller#1384
@JoelSpeed
The text was updated successfully, but these errors were encountered: