Tobs version telemetry is capturing Promscale version

[VineethReddy02]

What happened?

The version telemetry shared by Tobs is not the version of Tobs helm chart. We are capturing the Promscale helm chart version as the env value: "{{ .Chart.Version }}" set in Promscale env and it's capturing the version specific to Promscale helm chart.

Did you expect to see something different?

The Promscale version is already captured in Promscale telemetry. I expect to see Tobs version here.

How to reproduce it (as minimally and precisely as possible):

Installing the Tobs and verifying in the Promscale telemetry table shows the version as the Promscale version.

Anything else we need to know?:

At the moment our telemetry with this datapoint isn't right as its Promscale version and of almost zero value to us.

[paulfantom]

Since 12.0.0 is out now and we don't have CLI application, we can consider refactoring telemetry. It means we should fix issue reported here as well as in #467 while still keeping relevant datapoints. Considering that we heavily changed tobs release process and we are on the way to do the same for promscale helm chart, the question is if we do still see any value in having helm chart version sent via telemetry? Would it maybe make more sense to ship only the following datapoints and correlate the data during analysis:

• promscale version used (I believe this is already sent either way)
• promscale installation method (tobs/helm/k8s-manifests/container/system)
• features enabled in tobs (timescaledb, kube-prometheus, otel-operator, ...)

With such dataset we can see if tobs is adopted, if it is updated (by seeing if promscale is updated), which features are used, etc.

---

From an engineering perspective, it would be relevant to know the following:

• which tobs modules are enabled (timescaledb, promscale, kube-prometheus-stack, otel-operator)
• which tobs variants are used (variants as defined in Offer multiple modes of Tobs installation #473)
• which kubernetes versions are used
• is promscale installed using its helm chart, generated manifests, tobs, other

---

Either way if we require sending tobs helm chart version, then this fix might be a bit more complicated as apparently, subcharts do not have access to parent chart variables.

[VineethReddy02]

Currently, the recorded helm chart version is the Promscale version. We need to capture the Tobs version for the below reasons:

1. To understand the installs, and upgrades specific to each version.
2. The version from telemetry helps us in the supportability matrix.

We cannot rely on the version of Promscale to track back Tobs version as the releases are not tied to each other and as Tobs now is a separate product itself having its own version in telemetry offers better visibility.

Regarding data points and correlating the data during analysis:

1. Promscale version is already captured.
2. The installation method is also captured.
3. Features enabled in Tobs: Definitely offers more visibility into custom installations.

I agree we need these data points:

1. Which modules are enabled: As I mentioned above, more visibility into custom installation would be a value addition to the product.
2. Which tobs variant is used? As these are separate values.yaml so we should have a datapoint for each values.yaml denoting its variant for telemetry.
3. K8s version: We definitely need this.
4. We already how Promscale is installed, not sure on K8s manifest files-based installation.

I like all additional feedback shared for telemetry (noted for telemetry enhancements). But adding to that we definitely need Tobs version in telemetry. Maybe we can achieve this by adding it the actual value in Tobs values.yaml Promscale env variable (suggestion on top of my mind). Again, it's the engineering call on how to capture the version.

[paulfantom]

We cannot rely on the version of Promscale to track back Tobs version as the releases are not tied to each other and as Tobs now is a separate product itself having its own version in telemetry offers better visibility.

Yes, correct. The question was if tobs version is useful at all considering we are releasing few times a week. If it is useful, could you tell how?

The version from telemetry helps us in the supportability matrix.

What supportability matrix? If you mean this then IMHO more informative would be to track kube version instead of tobs version.

---

The installation method is also captured.

We already how Promscale is installed

I am under impression that we don't have enough granularity in those. For example there is no distinction between installing via plain manifests vs helm chart. Also we need to refactor this mechanism to satisfy #467

---

[VineethReddy02]

I agree with your point on this will end up with too many versions on the telemetry database. But capturing this should not cost us anything. IMO we do not release the major versions often, so tracking them offers us visibility to the major version (I'm not interested in the exact patch release):

1. Most commonly we need this to track the installed version. (we have seen with Promscale, that some users prefer to use specific versions though the latest is available).
2. It helps to understand different versions that users are running and the upgrades they are performing.

For any product, we need the version to understand what version the user is exactly running and how old it is and the versions it went through with upgrades.

Atm on the telemetry end this is what we see for Tobs version breakdown, which is Promscale versions:

Btw from the product end, I am not asking to introduce a new telemetry datapoint. This already existed in Tobs (hoping that it's capturing Tobs version, but lately we discovered this isn't doing its job). So all we need is to fix this, I do not agree just because it's hard to capture, we need more reasons to capture it. :)

[VineethReddy02]

I agree on telemetry for manifests vs helm. We need some flag to capture manifest-based installation but that falls under Promscale repo. So let's discuss telemetry specific to the Promscale manifest file in the Promscale repo.

Now we are able to already capture: Promscale helm-based install, Tobs helm-based install, and Tobs CLI-based install.

[paulfantom]

IMO we do not release the major versions often

With the new release process, there is no data to back this up. We will be releasing major versions every time there is a breaking change. For example 13.0.0 is just around the corner with #546 and we released 12.0.0 just ~10 days ago.

Now we are able to already capture: Promscale helm-based install, Tobs helm-based install, and Tobs CLI-based install.

Yes, but this causes issues on tobs side (#467) and thus needs refactoring. So we can use this time to make it much better not just slightly better.