argoproj / argoproj/argo-workflows
Generic Init Container Name Causes Duplicate Name Errors
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 17k
- Forks
- 3.7k
- Avg merge
- 1d 20h
- Merged PRs (30d)
- 138
Description
Summary
The init container created by Argo Workflows has the name init, which is generic and as we're seeing is used across multiple tools that are outside of our immediate control to modify. This creates a duplicate value error.
task 'my-task' errored: Pod "my-task-2155954101" is invalid: spec.initContainers[1].name: Duplicate value: "init"
Use Cases
For our specific use case, we are using Argo Workflows and the Akeyless Kubernetes Plugin, both of which use init containers named init. The Akeyless plugin is used to fetch secrets and inject them into our pod, following 12-factor principles. We do not have the ability to modify either of these init container's names, unfortunately. We've also raised a request with the Akeyless team, but imagine at some point someone else will run into this issue with Argo Workflows.
We'd love to either have the init container be named something more specific, argo-workflow-init, or have the ability to make it dynamic.
Thanks! If we do have the ability to overwrite and just missed it, please let us know.
Message from the maintainers:
Love this enhancement proposal? Give it a 👍. We prioritise the proposals with the most 👍.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Locate the code that creates the workflow init container and check whether its name is configurable. Reproduce the collision with another init container named init, then verify that the chosen behavior prevents duplicate names without breaking normal workflow execution.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, kubernetes
- Domain
- backend, infrastructure
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100