Component(s)
helm
Is your feature request related to a problem? Please describe.
When running on our environment (GKE), we need to run a native sidecar cloudsql-proxy to talk to our Cloud SQL Postgres database. To be able to do so, we configured it as a native sidecar on our controlplane, which works fine.
When running the migration-jobs though, there is no support to define or reuse this initContainer setting.
Describe the solution you'd like
I would like to propose to extend the job-configuration fields with an optional initContainers - just like for the deployment. This way users can influence themselves whether they want initContainers for their jobs as well, and for which ones. It is a noop for users who don't need this.
Describe alternatives you've considered
We could reuse the existing initContainers configuration, but that would add the initContainer also to the jobs that actually do NOT need to have that specific initContainer.
Additional context
No response
Component(s)
helm
Is your feature request related to a problem? Please describe.
When running on our environment (GKE), we need to run a native sidecar cloudsql-proxy to talk to our Cloud SQL Postgres database. To be able to do so, we configured it as a native sidecar on our controlplane, which works fine.
When running the migration-jobs though, there is no support to define or reuse this initContainer setting.
Describe the solution you'd like
I would like to propose to extend the job-configuration fields with an optional
initContainers- just like for the deployment. This way users can influence themselves whether they want initContainers for their jobs as well, and for which ones. It is a noop for users who don't need this.Describe alternatives you've considered
We could reuse the existing initContainers configuration, but that would add the initContainer also to the jobs that actually do NOT need to have that specific initContainer.
Additional context
No response