Here are examples of telemetry data that would have been and would be super useful for rpm-ostree based variants such as Fedora CoreOS or Fedora Silverblue / Kinoite.
For each telemetry report, the base operating system version (Version from rpm-ostree status -b) would also be reported alongside the data to be able to correlate issues with the exact package versions. if a user had made changes (overlayed packages, etc.), we would only report the base version, not the overlay specific one.
Examples:
-
Number of successful / failed rpm-ostree operations (mostly updates and rebases):
- This would let us see if users on a specific release are having issues updating and if we need to send an announcement, for example for a bug fix or a workaround.
- Ideally those bugs would be caught before they reach users but we’ve already had such a bug happen:
-
Number of successful / failed Flatpak installations and updates:
- Similarly to the metric above, this would let us see if a newer releases have more/less Flatpak installation failures, even before users report issues.
- This could have helped catch the ostree bug even before someone would have reported it:
-
Number of podman successful / failed container creations / start failures:
- This would let us see if a newer podman or kernel version is triggering a lot of container failures.
- This could have helped us diagnose the kernel ulimit change:
-
Hardware and cloud platform (a little bit like Steam hardware reports):
- This would let us know which cloud platforms and hardware are most used and where effort would be needed.
- If a platform is non existent in our data but has a big market share then it likely means that we need to make Fedora better on it.
- If a platform has a lot of users then it means that bug impacting this platform should be release blocking.
- How much of our users need NVIDIA drivers?
-
Number of Flatpaks installed, number of Flatpak remotes
- Note that this would not report remote names, only the amount of remotes
- We could consider doing special cases like: “Is the Fedora remote enabled?” / “Is the Flathub remote enabled?”
- This would enable us to answer questions such as:
- “Which percentage of our installation base has the Fedora remote enabled?”
- “Which percentage of our installation base has Flathub enabled?”
-
Number of overlayed packages, number or overridden packages:
- Not reporting the exact packages, only the number of added / changed packages.
- This would enable us to answer questions such as:
- “Which percentage of our installation base has no package overlayed?”
- “Which percentage of our installation base has more than X packages overlayed?”
-
Number of non Fedora package repositories:
- Similarly to Flatpak remotes, some repos (RPM Fusion) could be special cased.
- This would enable us to answer questions such as:
- “Which percentage of our installation base has RPM Fusion enabled?”
-
More Fedora CoreOS specific example:
- Size of the Ignition config (not its content)
- Whether some features where used (remote config, etc)
- This would let us know where to put our effort on Ignition maintenance and future features.
Fedora CoreOS also has a long topic discussing collecting metrics by default (with an easy opt-out): Collect metrics from Fedora CoreOS machines · Issue #86 · coreos/fedora-coreos-tracker · GitHub. This has mostly not happened due to lack of development time.