Remove non-existent imagePullSecrets from CSI controller Deployment

[pangwangshu]

What this does

Removes the hardcoded imagePullSecrets: - name: image-pull-secret block from the csi-oci-controller Deployment pod spec, in both:

• manifests/container-storage-interface/oci-csi-controller-driver.yaml (static manifest)
• manifests/container-storage-interface/csi/templates/oci-csi-controller-driver.yaml (Helm chart template)

Addresses #510.

Why

image-pull-secret is never created by any manifest, RBAC file, or documented setup step in this repo — the only secret the CSI docs instruct users to create is oci-volume-provisioner (OCI API credentials), which is unrelated. All images pulled by this Deployment (ghcr.io/oracle/cloud-provider-oci, registry.k8s.io/sig-storage/*) are public and need no pull credentials.

Because imagePullSecrets is resolved unconditionally by the kubelet regardless of whether the image is public, a fresh install fails with FailedToRetrieveImagePullSecret and the controller pod goes into CrashLoopBackOff/ContainerCreating until a user manually creates a dummy secret with that exact name — a step that exists nowhere in the documentation.

The sibling csi-oci-node DaemonSet manifest (and its Helm template) pulls the exact same public images and has no imagePullSecrets entry at all, and works fine. No other manifest in the repo (CCM, flexvolume-driver, volume-provisioner) has this field either. This confirms the reference was leftover/vestigial rather than an actual requirement, and removing it brings the controller Deployment in line with every other manifest in the project.

Validation

• Repo-wide grep confirms no remaining references to image-pull-secret anywhere (manifests, docs, scripts).
• Parsed the static manifest with PyYAML and the Helm template (with template actions stripped to simulate a render) — confirmed the resulting pod specs are identical to the pre-fix versions except for the removed imagePullSecrets key; containers, volumes, etc. are unchanged.
• No Go code is touched by this change, so govet/golint/gofmt/build/test targets are unaffected.
• helm template wasn't runnable in the sandbox this change was prepared in (no network access to fetch the Helm binary), but the structural check above covers the equivalent risk, and there is no existing CI job that lints/templates this chart.

How to test manually

1. Deploy the CSI controller manifest (or Helm chart) from this branch to a cluster configured for the OCI CSI driver.
2. kubectl -n kube-system get pods -l app=csi-oci-controller — confirm the pod reaches Running without any FailedToRetrieveImagePullSecret warnings or CrashLoopBackOff.
3. kubectl -n kube-system describe pod <csi-oci-controller-pod> — confirm there are no image pull secret-related warnings in the Events section.

[oracle-contributor-agreement]

Thank you for your pull request and welcome to our community! To contribute, please sign the Oracle Contributor Agreement (OCA).
The following contributors of this PR have not signed the OCA:

• PR author: pangwangshu

To sign the OCA, please create an Oracle account and sign the OCA in Oracle's Contributor Agreement Application.

When signing the OCA, please provide your GitHub username. After signing the OCA and getting an OCA approval from Oracle, this PR will be automatically updated.

If you are an Oracle employee, please make sure that you are a member of the main Oracle GitHub organization, and your membership in this organization is public.