ratify icon indicating copy to clipboard operation
ratify copied to clipboard

Investigate/fix CRD conversion mechanism

Open binbin-li opened this issue 2 years ago • 1 comments

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.

binbin-li avatar Sep 22 '23 06:09 binbin-li

Investigation on the CRD conversion webhook:

  1. metadata.name and metadata.namespace are immutable, so CRD conversion webhook cannot update it.
  2. Currently we select unversioned as a Hub version. To make it work with CRD conversion webhook, we need to remove the unversioned and set v1beta1 as the Hub version, v1alpha1 as the spoke version.
  3. We need to install cert-manager to generate certs and inject CA bundles to webhooks.
  4. 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
  5. Basically we follow the kubebuilder tutorial to set up the conversion webhook. https://book.kubebuilder.io/multiversion-tutorial/conversion
  6. An example PR that adds the conversion webhook: https://github.com/binbin-li/ratify/pull/111

binbin-li avatar Oct 23 '23 02:10 binbin-li