ratify
ratify copied to clipboard
Investigate/fix CRD conversion mechanism
What happened in your environment?
If user is running a previous Ratify version with v1alpha1 policy, once users upgrade to v1beta1 policy, Ratify cannot read existing CR objects in v1alpha1 as the conversion method seems not triggered.
We need to find out why the conversion logic is not triggered and make it working for CRD multi-version compatibility.
What did you expect to happen?
No response
What version of Kubernetes are you running?
No response
What version of Ratify are you running?
No response
Anything else you would like to add?
No response
Are you willing to submit PRs to contribute to this bug fix?
- [ ] Yes, I am willing to implement it.
Investigation on the CRD conversion webhook:
-
metadata.nameandmetadata.namespaceare immutable, so CRD conversion webhook cannot update it. - Currently we select
unversionedas a Hub version. To make it work with CRD conversion webhook, we need to remove theunversionedand setv1beta1as the Hub version,v1alpha1as the spoke version. - We need to install
cert-managerto generate certs and inject CA bundles to webhooks. - A patch update would be applied to CRDs, which requires Ratify's namespace. And since CRDs cannot be templated in Helm, namespace would be hardcoded and updated per namespaces. e.g. example
- Basically we follow the
kubebuildertutorial to set up the conversion webhook. https://book.kubebuilder.io/multiversion-tutorial/conversion - An example PR that adds the conversion webhook: https://github.com/binbin-li/ratify/pull/111