Is it possible to have specific webhook for each version of the same kind?

[mhshams]

Following the book, I've created 2 versions of a kind (Foo). Let's say v1 and v2.
The v1 is the storageversion and the Hub. Each version has a defaulter and validator separately.

When I am creating v1 or v2 resources only the v2 mutation and validation endpoints are being called.
Is this the expected behavior?

I was expecting v1 endpoints to be called for v1 resources and v2 endpoints for v2 resources.

[camilamacedo86]

To answer the user's question:

Yes, this is the expected behavior when dealing with conversion in Kubernetes CRDs. Here's why:

Storage Version:

When you said v1 is the storage version, it means that all the objects of Kind Foo, irrespective of their API version, will be stored in etcd in the v1 version. So, whether you submit a v1 or v2 object to the API server, before persisting to etcd, it will be converted to the v1 version.

Conversion Webhooks:

The conversion webhooks are responsible for converting objects between different versions. When an object is submitted to the API server (either for reading or writing), it might need to be converted to a different version. This is where the conversion webhook comes into play.

In your case, if you submit a v1 object, but you're using a v2 client (or vice versa), the conversion webhook is responsible for handling this translation.

Defaulters & Validators:

Here's where it gets a bit tricky. Given the setup you described, Kubernetes will:

Convert the object to the Hub version (v1 in this case) using the conversion webhook.
Apply the defaulter for the version you're working with (v2 in this case).
Validate the object using the validator for the version you're working with (v2).
If all goes well and the object is to be persisted, it will be stored in etcd in the storage version (v1).
This is a simplification, but the essence is: even if you're working with a v1 object, because you have a newer version (v2) with a defaulter and validator, Kubernetes will use the newer version's logic (after converting to that version) to perform those operations.

In short, the behavior you're observing is expected given Kubernetes' CRD versioning and conversion mechanisms.

I hope that helps you out
So, I am closing this one as answered
Feel free to re-open if you need to