Open Joibel opened 1 month ago
This makes sense. I think we should not limit this only to SDK but offer support for all languages.
A PR is welcome
This makes sense. I think we should not limit this only to SDK but offer support for all languages.
Can you clarify what you mean here please? I only have limited understanding of the auto-instrumentation mechanisms. I'm pretty sure we can't auto-instrument a go init container as that involves a sidecar which I don't believe you can do with an initContainer.
The other auto-instrumentation all(?) rely on initContainers with shared volumes, so I guess they could be made to work and auto-instrumentation if we ensure the instrumentation initContainer runs before them, is that what you were hoping for them?
Component(s)
auto-instrumentation
Is your feature request related to a problem? Please describe.
I am adding tracing to argo-workflows to allow collection of a trace of the actual workflow.
When a workflow executes a workload in a pod it will create the pod with an initContainer which does various bits of setup of the workflow, including downloading of any artifacts (files) which the pod may use during execution.
I would like to be able to capture this as part of the overall workflow trace.
Describe the solution you'd like
When a
container-names
annotation is present on a pod I would like the SDK environment variables to be present in the initContainers whose names are present in the annotation.Describe alternatives you've considered
I can manually inject the constant SDK variables, but this is also the case for anyone using the operator annotations for SDK injection. I would like the convenience of the operator to help me here too, especially for the non-constant values.
Additional context
I have a POC which does this. The code change is relatively small. I am willing to make the PR.
I am unsure whether any of the specific injectors should also honor this on initContainers - so would like guidance on that.