Conversion via CEL

[Austin Cawley-Edwards]

Hey all,

Been trying to keep up with the progress of CEL and wondering if using CEL for conversion (vs. webhooks) has been discussed / is at all feasible.

Best,

Austin

[Austin Cawley-Edwards]

Great links, thanks! Out of curiosity, what do the cases where people reach for versioning but not need it look like?

On Thu, May 2, 2024 at 15:59 Nic Cope <ne...@upbound.io> wrote:

This is relevant to our interests in the Crossplane project too.

We see a lot of folks who think they need conversion, but really don't. For folks who really do, something declarative would be preferred over needing to roll a webhook. Here's what I'm aware of in the space so far:

• https://github.com/kcp-dev/kcp/pull/2105 - Support in kcp
• https://github.com/kubernetes/enhancements/pull/3947 - An abandoned KEP

--
You received this message because you are subscribed to the Google Groups "K8s API Machinery SIG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-api-m...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-api-machinery/983fa367-c95f-4f88-8864-91ae0df7fb26n%40googlegroups.com.

--

Thanks,

Nic

[Nic Cope]

This is relevant to our interests in the Crossplane project too.

We see a lot of folks who think they need conversion, but really don't. For folks who really do, something declarative would be preferred over needing to roll a webhook. Here's what I'm aware of in the space so far:

• https://github.com/kcp-dev/kcp/pull/2105 - Support in kcp
• https://github.com/kubernetes/enhancements/pull/3947 - An abandoned KEP

On Thu, May 2, 2024 at 11:28 AM Austin Cawley-Edwards <austin...@gmail.com> wrote:

--

You received this message because you are subscribed to the Google Groups "K8s API Machinery SIG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-api-m...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-api-machinery/983fa367-c95f-4f88-8864-91ae0df7fb26n%40googlegroups.com.

--

Thanks,

Nic

[Nic Cope]

On Thu, May 2, 2024 at 5:28 PM Austin Cawley-Edwards <austin...@gmail.com> wrote:

Great links, thanks!

 

Out of curiosity, what do the cases where people reach for versioning but not need it look like?

For context, the average Crossplane user isn't a seasoned Kubernetes developer - they might just be learning about CRDs. A lot of what we see is folks just starting out, and wondering how API versioning is going to work when they need it.

The desire to introduce a new version starts to cool off once folks realize:

• They can evolve an API a lot without needing a new version, for example by adding new optional fields
• That adding a new version isn't a silver bullet - e.g. you can't just drop a previously required field, or add a new required field

Don't get me wrong, there are definitely cases where folks would benefit from versioning (e.g. renaming or moving a field). That's why we're interested in declarative conversion using CEL or similar. However I think the first step for us in Crossplane should be writing better documentation and tooling to help folks design APIs that may never need a new version.

--

Thanks,

Nic

[Joe Betz]

I agree.  When thinking about CRD schema evolution, it’s important to get as much mileage as possible by making backward compatible changes to the existing version.

For example, introducing a new CRD version in order to add new fields is typically a mistake since the CRD versions need to be able to convert losslessly between each other.

I don't have any objection to an enhancement that adds CEL CRD conversion support (there is prior art in KCP), but I consider safe single version CRD evolution significantly more urgent.  So if anyone does have a legitimate need for CEL CRD conversion, they might need to drive the effort.  But honestly, if that energy could instead be directed at making CRD evolution safer, I think the community might benefit more from that.

Better documentation about all this is certainly needed.  I'll see if I can carve out some time for that.

-Joe

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-api-machinery/CAKraHCH5TkYZCpSKWd91f1JN_zvMnzQgu_k1-_6M5xzem1a%2Bew%40mail.gmail.com.