remove references to stack helm chart version

[shainaraskas]

The helm chart version is not static and often gets bumped with an ECK release.

this PR skips the value completely so we no longer need to worry about it being out of date

[github-actions]

🔍 Preview links for changed docs

• deploy-manage/deploy/cloud-on-k8s/managing-deployments-using-helm-chart.md

[rhr323]

LGTM. Thanks for the improvement!

[eedugon]

IMO the usage we do of the eck_helm_chart_version doesn't justify the creation of the substitution.

We are using it only in an example for illustration purposes of how the Ingress would look like, and the important part of the content is the Ingress payload itself, not really the labels. So, the focus should be on the spec and rules of the content, and not on the labels (I'm sorry because I introduced these examples).

So, if we want this substitution only to solve this, I think it would be better to remove the labels from the illustrative examples instead of creating a new subs that we will have to maintain.

But of course, if there's benefit on mentioning on our docs the latest helm chart release and explain if different helm chart releases support different things (maybe in the future), then we would definitely need this.

WDYT @rhr323 or @barkbay ?

I think the doc would still be ok if we leave something like:

metadata:
  name: elasticsearch
  labels:
    ...
    ...
spec:

PS - Note that when I added the ingress example I did it because it's useful to see how an Ingress object for an ECK-managed resource could look like in case a user wants to create ingress objects manually, which is a common use case also.

[shainaraskas]

@eedugon great points. will let the devs weigh in on what they think is best.

[barkbay]

Sorry for the delay, this one fell through the cracks.

LGTM, left a small comment about naming.

[barkbay]

Sorry I read the PR content first, and missed @eedugon's comment 🙃

I think it would be better to remove the labels from the illustrative examples instead of creating a new subs that we will have to maintain.

No strong opinion, but what you said makes sense to me.These labels don’t seem to add much value; we could indeed consider removing them.

[shainaraskas]

@barkbay I took @eedugon's suggestion and cut this out to reduce the number of things to update as part of a release.

[yetanothertw]

LGTM 🐈

[barkbay]

LGTM

[eedugon]

LGTM!