[jaeger] add possibility of overriting the namespace

[rzjfr]

What this PR does

Adds possibility to override the namespace of the resources

Which issue this PR fixes

(optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format,
will close that issue when PR gets merged)

• fixes #

Checklist

• DCO signed
• Commits are GPG signed
• Chart Version bumped
• Title of the PR starts with chart name ([jaeger] or [jaeger-operator])
• README.md has been updated to match version/contain new values

[pavelnikolov]

This is the first PR I see that changes both the jaeger and jaeger-operator charts at the same time.

@rzjfr Regarding the jaeger chart upgrade, until now, one could override the namespace using --namespace helm flag when installing the chart. It seems that this is not enough for your use case(s) for some reason 🤔

[rzjfr]

Hi @pavelnikolov thanks a lot for the review,

You are absolutely right, you can use --namespace and adding these changes meant to be backward compatible and not break that. Whoever there are cases which explicitly setting the namespace and/or overriding it could be useful. For example if you want to use the chart as a subchart and you want the jaeger to be deployed in a namespace other than the parent or other sibling charts. These kind of complex use cases are more common if you use a single application in argoCD for example or spinnaker and from what I see public charts mostly accommodate overriding the namespace.

So the idea is the change to be absolutely backward compatible, while adding that possibility if someone needed it.

[pavelnikolov]

This is an interesting use case. I appreciate the backwards compatibility thinking, however, I was wondering if you are installing Jaeger in a namespace different than the (parent chart's) release namespace, then shouldn't you create that namespace as well? Have you tested if that change would actually work?
In addition to that, it seems that the chart version needs to be bumped and other items from the PR checklist taken care of.

[rzjfr]

Hi again @pavelnikolov,
Thanks for the quick review and sorry for the delay,
I have tested the charts, not every edge case but it was working fine with couple of quick tests

[pavelnikolov]

@batazor @cpanato this PR LGTM from the jaeger chart from PoV. Do you have some comments related to the operator chart?

[pavelnikolov]

@yurishkuro wdyt about updating both charts within the same PR? It seems that this isn't a common practice.

[yurishkuro]

@pavelnikolov I have not been involved in this repo's development, so don't have any strong opinion. There is a general principle of keeping PRs small, from that perspective I would split it into two, one per chart. But as far as any functional impact - I don't know.

[batazor]

@rzjfr If we talk about ArgoCD, there is no problem there to deploy helm chart in any namespace

If you want to change something in the child helm chart - you can use kustomize and override the chart values, ArgoCD works fine with kustomize.

[rzjfr]

@batazor thanks for your comment, I agree that there are some ways to use this chart as is under the circumstances I described but the purpose the changes proposed here are to make it easier, they are backward compatible and the idea is a very common practice.
For example almost every chart that this chart depends on has the same mechanism in place (here).

[batazor]

@rzjfr Yes, then it would be cool - at least separate jaeger and jaeger-operator - as written earlier, we try to avoid changing more than one service at a time