Feature Overview (aka. Goal Summary)

As a MicroShift product manager, I would like to see telemtry data about product usage so I can better understand where and how the product is used.

Customers want to have the same remote health monitoring capabilities as they have with OpenShift and RHEL 

Goals (aka. expected user outcomes)

• Get insights about how customers use microshift

Requirements (aka. Acceptance Criteria):

1. The data product management is  specifically interested in is:
   • per deployment:
     • number of available cores/RAM/disk/NICs
     • average utilisation of cores/RAM/disk/network (% of total)
     • number of namespaces
     • number of running pods
     • number of container images on disk
     • number of routes/ingress/services
     • number of CRDs (to determine operator usage)
     • os version / type (rpm / ostree)
     • ???
   • per fleet (can we identify the fleet the edge belongs to, e.g. all devices with same  ostree commit id?)
     • number of devices in fleet
2. This should re-use existing telemetry  infrastructure Red Hat has already in plce. Either the OpenShift telemetry or the Insights infrastructure. Whatever has less footprint.
3. As with OpenShift and RHEL, customers need a way to opt-out of this "call home" capability (see https://docs.openshift.com/container-platform/4.14/support/remote_health_monitoring/opting-out-of-remote-health-reporting.html)
4. As with OpenShift and RHEL, customers need to be able to fully understand how and what telemetry data is sent back to Red Hat Servers (e.g. like https://docs.openshift.com/container-platform/4.14/support/remote_health_monitoring/about-remote-health-monitoring.html)
5. If the cluster has configured/requires a proxy to connect to the internet / Red Hat, that should work.

Out of Scope

1. Observability / Monitoring data for customers. This is handled via https://issues.redhat.com/browse/OBSDA-455
2. Telemetry / Insights in a restricted network (no internet connection, not even via proxy)

Background

n/a

Customer Considerations

none

Documentation Considerations

• Configuration option needs to be documented in the "Support" 

Interoperability Considerations

None