Add EP for CatalogSource pod spec override

[perdasilva]

Signed-off-by: Per G. da Silva perdasilva@redhat.com

Description

#2454 asks for a way to override parts of the pod spec supplied to the underlying pod created when spec.sourceType == grpc and spec.image is defined.

This EP outlines a few different options to address this issue

[fgiloux]

I'm not clear on why it's important that the catalogsource be running on a particular node? I would think it would matter more where each operator pod is scheduled. I just want to make sure we're not trying to solve the latter with the former.

Generally it should be possible for a cluster-admin to decide on which node any pod, including the ones created for the catalogsource is running. There are several reasons for that:

• nodes with special hardware need to be kept for special workload, i.e. GPU for model training
• security aspects: sensible workload or user workload may need to be separated from infrastructure
• nodes may be reserved for privileged operations like builds
• cost aspects: In OpenShift it is possible to label nodes as infrastructure. They don't incur subscription cost but cannot be used for any workload.

[gallettilance]

@fgiloux Thanks - I see how it's a nice to have but I'm worried that the above points don't really apply to the catalogsource pod that is only serving a grpc endpoint. I feel these points apply more to workloads deployed from the catalog by OLM - which is unrelated to where the catalog pod is running. I just don't want users of this feature to get the wrong idea.