Telemetry should include preset

[deboer-tim]

The telemetry events for start, stop, commands do not include which preset is used. It would be good to log whether MicroShift or OpenShift Local is being used so we can prioritize between the two or understand when (e.g.) a behaviour or error is prevalent in one vs the other.

[gbraad]

This is recorded in the backend upon the start call. Stop has no meaning in relation to the preset, although is related to the same user. There is no use to record this multiple times, right? In the tray we also did not record this specifically as the extension and tray have no implicit knowledge about this presets; they merely call into the rest API.

On Tue, Jun 13, 2023 at 11:00 PM Tim deBoer @.***> wrote:

The telemetry events for start, stop, commands do not include which profile is used. It would be good to log whether MicroShift or OpenShift Local is being used so we can prioritize between the two or understand when (e.g.) a behaviour or error is prevalent in one vs the other.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: @.***>

--

Gerard Braad | http://gbraad.nl

STEM is the source, but BUILD is how you develop! [ Better Understanding Involves Learning and Doing ]

[deboer-tim]

Yes, no real need to record it twice, but it is usually easier when the data is in whichever relevant event you want to filter by. e.g. start is likely one we'd want to compare the profiles (or whether users behaviour is different for the preset, e.g. do they start/stop one on demand vs leave the other running? how long do users typical run it?), so I'd include it in there even if there was an init/creation event that already included it.

The key thing we wanted to know is 'how much are people using MicroShift or OpenShift within Podman Desktop'. Unless the backend knows what triggered the action, the only place to get this would be via the Podman Desktop telemetry. Even if the extension has no real need to know IMHO it's worth one extra backend call to include this in telemetry/logs.

[gbraad]

The migration from Woopra to Amplitude might have dropped it from a view. I have asked Praveen to update the Amplitude views last week as we have the data.

--

Gerard Braad | http://gbraad.nl

STEM is the source, but BUILD is how you develop! [ Better Understanding Involves Learning and Doing ]

[gbraad]

Yes, no real need to record it twice, but it is usually easier when the data is in whichever relevant event you want to filter

https://github.com/crc-org/crc/blob/079ea4c9f0db9e5cc3bbeffa8d9c8ca3526c82ac/pkg/crc/api/client/types.go#L16-L20

how much are people using MicroShift or OpenShift within Podman Desktop'

Every call records the originator for our backend telemetry

https://github.com/crc-org/crc/blob/079ea4c9f0db9e5cc3bbeffa8d9c8ca3526c82ac/pkg/crc/api/client/types.go#L62C1-L66

So the filter should include the source and clusterconfig.preset

Note: I do not have rights to modify these views.

---

we are limited by the telemetry as what is provided by PD: I believe we can only record string identifiers as part of the logUsage: https://github.com/crc-org/crc-extension/blob/7d6aa22b8b8801efcae3bcf7772a5555822a27d7/src/command.ts#L76

I had worked on our own client: https://github.com/gbraad-redhat/crc-extension/commit/8b4ba4956763907192c90454a901e79231202cdc but it was decided to re-use the unified telemetry option.

Do we need to expand the TelemetryLogger?

---

correction. Seems this is possible now:

https://github.com/containers/podman-desktop/blob/c3db2ed0ec79f9c1e5ca0e2e2875b42ad0b82df9/packages/extension-api/src/extension-api.d.ts#LL1851C1-L1851C91

data?: Record<string, any | TelemetryTrustedValue> can be included as record or accepted value

logUsage(eventName: string, data?: Record<string, any | TelemetryTrustedValue>): void;

---

Note: Even though the telemetry can record 'data', the 'preset' is not stored as actual state inside the extension. The truth (true value) is stored in the backend/daemon. The start does not instruct what preset is started. Preferences/settings is not stored in the extension. All calls for this is performed as crc config get/set commands. Which means, if we wanna record the preset value on start, we would need to perform an additional status command; we can use the temporary stored currentStatus for this, but it is a possible inaccurate representation.

crcStatus.status.Preset