Closed tglanz closed 1 year ago
Am wiling to work on it if that's something your'e interested in adding
@tglanz I think you're right, this should be supported.
But this brings up the point again that @dmitryax has made in the past: should we be using the jaeger helm chart as a subchart instead of adding these capabilities ourselves? A quick look at the jaegar chart and it appears to support ElasticSearch as a storage solution as well as env vars, affinities, tolerations, and node selectors.
@puckpuck do you see any downside to using the jaeger chart as a sub chart?
@TylerHelmuth I'm not sure but it looks like Jaeger's chart doesn't support in-memory mode? Which is this chart's default
Moving to a Jaeger chart is a good idea here.
The downside is we may break backward compatibility for anyone that configured something specific to the Jaeger deployment.
Yes, I believe we need to use the jaeger helm chart as a sub-chart. We may be able to support the current jaeger config interface as deprecated and translate it into the sub-chart config, but it may be too much work
@tglanz it looks like the chart can support in-memory mode/all-in-one which is good news for us.
Since this chart is relatively new, for a demo, and doesn't supply that many configuration options for jaeger I would be in support of introducing the jaeger subchart as a breaking change.
The breaking change would also be the catalyst to do a proper readme for the chart as well finally.
I went down the path of using Jaeger as a sub-chart.
Unfortunately, the Jaeger Helm chart doesn't implement a way to pass in extra args for the all-in-one
mode. I still think doing Jaeger as a sub-chart is a good idea, but now I need to figure out how to PR a change into the Jaeger helm chart.
I'd like to use an ElasticSearch cluster as a storage backend for Jaeger. For this I need to set some environment variables in Jaeger's containers. Some of the variables should be taken from the k8s cluster's secrets so it would be ideal to have an option configuring something like