feature request - be able to specify trace container(s) at runtime

[dalehamel]

I think the fastest way to add this would be via a command line switch, but that would be cumbersome to type out.

To override the builtin values more persistently, reading from an environment variable or configmap (though, not sure where that would be stored) could also work. A local config file (does kubectl standardize this in any way?) would probably be best long-term, as there's some other hardcoded values such us number of retries that could also be tweaked.

For developers, this would also be nice to be able to quickly test locally-built images (should the need arise), or test out new versions of bpftrace/bcc with a custom build.

This would also make it easy to A/B test containers for performance, or to work-around bugs such as in #52 for #51

[fntlnz]

@dalehamel I think you mean specify the image for the trace runner right ? I changed the title to reflect that let me know if I misunderstood.

I agree that there should be a way to just change the image at runtime, both for trace runner and the init container. Some users already reached telling me they weren't able to use kubectl trace without modifying the source to use an image that's behind their company proxy, this seems to be a solution to that too.

Last but not least, users with a very specific setup for which we can't guess kernel headers might want to create an image with the kernel headers they need directly.

[dalehamel]

Yeah this was about the trace container specifically, but I think should also apply to initContainer.

The company proxy is definitely an obvious use-case here too, and it's also a solution for optimizing a container to already have headers (negating any need for the initContainer)

Any thoughts on how to specify this? Re, flags, env vars, config file, etc?

[fntlnz]

I think I would also like @leodido opinion about wether it should be a flag or something else.
I think that we need this to be configurable both as a flag and as environment variable.

[leodido]

Atm we do not support environment variables. We could discuss whether to bind a environment variable to every flag we have.

BTW I agree on the need to have:

• --image-name
• --init-image-name (noop when fetching headers functionality is not explicitly enabled)

Furthermore, as emerged in #48, I would also implement a flag to explicitly enable the usage of an init container.

--fetch-headers (defaulting to false)

P.S.: working on it.