Oh my... are you sure that we want our CRDs to look like this? This update makes them 5 times bigger (~12Kb vs 62Kb) 😨
Initially, it was about the overrides documentation because it was a custom set of knobs, like a public switch, but do we really need to duplicate a well-known affinity object for this reason?
My main concern is that CRDs are now used in the CLI for object generation and commands auto-completion, so it is often loaded in memory. Making it this big without a clear reason may negatively impact the UX.

@tzununbekov @odacremolbap I've updated the PR to make the affinity arbitrary and I've added checks at the Webhook to verify things like some wrong names in the affinity.

Thanks. I see a lot of things done for the webhook and I'm struggling to find the reason. Could you point me to the code that implements webhook validation logic?

@tzununbekov There are some Unmarshal that are done automatically.

if I add an affinity like this:

  adapterOverrides:
    affinity:
      nodeAffinityy:

it will return this error at the creation time:

admission webhook "defaulting.webhook.triggermesh.io" denied the request: mutation failed: cannot decode incoming new object: json: unknown field "nodeAffinityy"

We could add more checks in the Validate func but I don't see what could we checks at this point

I'm pretty sure that the Defaulting webhook error is a side-effect of internal object processing and not its direct function; the Validation webhook should do that kind of validation. Nevertheless, we can live with that.

I tested the Affinity function and it doesn't work for me. I did some digging and it looks like it is not the way it works in the Knative. Are you sure that it works for you? Please try to create the Kn-based adapter and check if it is online.

@tzununbekov What do you mean that it doesn't works for you? I've tested creating a source, the adapter is running and checking if the deployment has the affinity set:

kubectl get deployment awss3source-sample -o jsonpath='{.spec.template.spec}'|grep affinity
{"affinity":{"nodeAffinity":{"preferredDuringSchedulingIgnoredDuringExecution":[{"preference":{"matchExpressions":[{"key":"zone","operator":"In","values":["zone-a"]}]},"weight":1}]}},"

About the Webhook, to check our objects with the webhook we need to add them to the NewDefaultingAdmissionController and NewValidationAdmissionController, if we don't add our objects there it doesn't check anything.

It looks like you tested only a Deployment-based component, not a Kn-based one. Knative serving, by default, does not allow setting the affinity parameter, it should be enabled through the Features and Extensions configuration. Otherwise, adapter deployment won't pass Serving validation. Btw, the same goes for the nodeSelector attribute:

Failed to create adapter Service "foo-transformation": admission webhook "validation.webhook.serving.knative.dev" denied the request: validation failed: must not set the field(s): spec.template.spec.affinity

IMO, this detail must have been mentioned because without knowing that, setting these adapter overrides may cost some hours of debugging the "outdated adapter specs" kind of issue.

Regarding the webhook implementation, I think we're on different pages. What I'm saying is that there is not much sense in having a webhook controller up and running while none of our components have Validation and Default methods implemented (those numerous SetDefaults and Validate methods that you created for all components and left empty - they are responsible for admission controller logic).
I see two options here:

1. Do not do any validation on our side and let the K8s controller handle incorrect overrides,
2. Define a common mechanism to run validation on shared objects (such as adapterOverrides) not to duplicate it on all resources.

I leaning towards the first option. Looks like Knative also does not care about validating these features (here).

We already have support for tolerations in the same way, I just follow that pattern.

Webhook:
The first option seems wrong to be, if we don't do any validations, k8s will not fail, the result will be the deployment created without the affinity attribute, and I guess that will require some more debug to check for users.

@FranBarrera can you please add an example of how can I add nodeSelector to the adapter?

Hi @mukundjalan nodeSelector was added in #1380

The syntax in the spec is

spec:
  # ...
  adapterOverrides:
    nodeSelector:
      disktype: ssd

Does that help ? We can discuss more on Slack if you want