[Bug FIX] init container indentation fix #5848
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This pull request resolves a Helm templating bug in the Emissary-ingress Deployment manifest. Previously, user-provided
initContainerswere incorrectly merged into theargsfield of the chart's internalwait-for-apiextinit container, causing deployment failures. The goal of this change is to ensure that custom init containers are correctly added as distinct, top-level entries within the Pod'sinitContainerslist.Related Issues
[If there's an existing GitHub issue for this bug, list it here, e.g., "Fixes #1234". If not, consider creating one and linking it.]
Testing
I've performed comprehensive local testing using
helm template --debugto inspect the generated Kubernetes manifests. This confirmed that theinitContainerssection in the rendered Deployment YAML now correctly includes both thewait-for-apiextcontainer and the customfix-log-permissionscontainer as separate, valid entries. Additionally, the updated chart was successfully deployed to a test EKS cluster, where thefix-log-permissionsinit container (using thebusyboximage andrunAsUser: 0) executed as expected. I verified that the target hostPath directory (/var/log/emissary) was created and writable, and that a Filebeat pod on the same node could successfully read logs from this location after its configuration was updated to include the necessary volume mount.Checklist
Does my change need to be backported to a previous release?
[Discuss with maintainers if this fix should be backported to older Emissary-ingress branches (e.g., v3.x, v2.x) if it affects those versions. If yes, state the versions here.]
I made sure to update
CHANGELOG.md.This is unlikely to impact how Ambassador performs at scale.
This change is a Helm templating fix and does not alter Emissary's runtime behavior, resource consumption, or scaling characteristics.
My change is adequately tested.
I updated
CONTRIBUTING.mdwith any special dev tricks I had to use to work on this code efficiently.The changes in this PR have been reviewed for security concerns and adherence to security best practices.