Remove hardcoded Operator-node affinity for temporary setup Pods to support standard OpenShift workload isolation

Summary of the Enhancement

Modify the CP4BA Operator so that it no longer hardcodes node affinity to its own host node when deploying temporary pods (used for PVC mounting and JDBC driver updates) into the operand namespace. The temporary pod should respect the scheduling constraints and node selectors of the target operand namespace.

Current Behavior & The Problem

In enterprise OpenShift environments, strict workload isolation is a standard practice. Infrastructure workloads (Operators) run on dedicated "infra" nodes, while Application workloads (Operands) run on dedicated application nodes (e.g., "cp4ba" nodes). This isolation is defined via the scheduler.alpha.kubernetes.io namespace annotations, which are then actively enforced by the OpenShift PodNodeSelector and PodTolerationRestriction mutating admission controllers.

Currently, the CP4BA Operator creates a temporary pod in the operand namespace to update JDBC drivers and mount PVCs. However, the Operator hardcodes the pod's node affinity to the exact node where the Operator is currently running (an "infra" node).

Because the target operand namespace enforces its own node selectors (forcing pods to "cp4ba" nodes), the OpenShift admission controller merges the namespace's constraints with the Operator's hardcoded constraints. This results in an unresolvable conflict (e.g., the pod requires a node that is labeled as both infra and cp4ba), leaving the temporary pod permanently stuck in a Pending state.

According to IBM Support, this hardcoded affinity was implemented to bypass image pull timeouts, as pulling the large operator image onto a new application node would cause the Operator's reconciliation loop to timeout and fail.

Business and Technical Impact

• Violates Kubernetes Best Practices: Hardcoding workload affinity to bypass a timeout issue is an antipattern that directly conflicts with core Kubernetes workload isolation principles.

• Deployment Blockers: This prevents CP4BA from being deployed in secure OpenShift environments that mandate namespace-level scheduling annotations.

• Resource Risk: It forces application-level tasks onto infrastructure nodes, which are meant to be reserved for critical cluster operations.

Proposed Solution We request that the engineering team implement one or a combination of the following solutions:

1. Remove Hardcoded Affinity: Stop forcing the temporary pod onto the Operator's node and allow the standard Kubernetes scheduler (and namespace admission controllers) to place the pod appropriately.

2. Provide a Configuration Toggle: Add a parameter in the CP4BA Custom Resource to explicitly disable this "image pull optimization" so the temporary pod is allowed to schedule cleanly within the operand namespace's constraints.