Feature #43956
closedmgr/dashboard: Provide an better workflow to "opt in" to enabling the telemetry mgr plugin
0%
Description
This is a follow-up to #36488, which added a way to configure the telemetry mgr plugin, but does not really provide an easy workflow or the option to review the generated report beforehand. This issue requests to make this feature more user-visible and encourage the user to enable it.
Upon a fresh cluster installation, it should be possible for the user to "opt in" and enable the telemetry plugin so we can obtain some metrics and statistics about the user's cluster.
Upon first login of an admin user on a freshly installed cluster, the dashboard should display a prompt that informs the user about the purpose of the metrics collection and should ask the user for confirmation to enable it.
It would be helpful to prompt the user for an email address (optional) and display a sample report of the data that is sent to telemetry.ceph.com.
Even if the user initially rejects the activation, the dashboard should still provide an easy way to enable this plugin later, following the same workflow as outlined above.
Also it might be sensible to re-ask the admin if he wants to activate the plugin after a major update?
Updated by Lenz Grimmer about 4 years ago
- Copied from Feature #36488: mgr/dashboard: Provide way to "opt in" to enabling the telemetry mgr plugin added
Updated by Tatjana Dehler about 4 years ago
Lenz Grimmer wrote:
display a sample report of the data that is sent to telemetry.ceph.com.
I'm wondering if we want to display the whole report in the dashboard or rather want to show a download button (or even both).
I'm also wondering where we want to display the sample report and if Cluster -> Manager modules -> telemetry might be a good place for it. Or if it's too less prominent.
A second idea would be to have a separate dashboard widget for the telemetry plugin to guide the user through the configuration and also to show a download button for the sample report.
Updated by Volker Theile about 4 years ago
I like option 2 with the widget.
Alternatively another idea would be to display a dialog after the first dialog which allows the user to enable the telemetry options and shows an example (which must not be the one from the current system). This solution can be easily implemented via Angular route guard :-) I know, another one, but this is a great solution to implement such behavior. The only challange is to store a flag that can be used to remember that the dialog has been displayed already.
Updated by Tatjana Dehler about 4 years ago
Volker Theile wrote:
I like option 2 with the widget.
Alternatively another idea would be to display a dialog after the first dialog which allows the user to enable the telemetry options and shows an example (which must not be the one from the current system). This solution can be easily implemented via Angular route guard :-) I know, another one, but this is a great solution to implement such behavior.
I'm not really sure what you mean by 'after the first dialog'. Or do you mean 'after the first login'? - In that case the dialog would only be shown once per user, right? - But what if the admin wants to see the sample report at a later point?
The only challange is to store a flag that can be used to remember that the dialog has been displayed already.
And that's not the only challenge as it's a system wide setting. Imagine the following: The admin logs in for the first time -> Does not enable the Telemetry plugin -> Creates another admin user. The second admin logs in and might enable the Telemetry plugin although the first admin decided against it?
I don't think this should be a per user setting. Maybe we can add a general dashboard setting "ask_for_telemetry_enablement" (or something similar) which is true until an admin passed the configuration dialog (either enabled the plugin or not). I'm wondering if it would be possible to reset the setting (to true) after each major update.
Updated by Volker Theile about 4 years ago
Oh right, seems to be more complex than it looks.
Updated by Lenz Grimmer about 4 years ago
- Related to Bug #44320: mgr/telemetry: fix and document proxy usage added
Updated by Lenz Grimmer about 4 years ago
I just learned via #44320 that it's possible to configure a HTTP Proxy for sending these outgoing HTTPS requests. I think it would make sense to allow the user to change this setting in this workflow as well (maybe as an "advanced option")?
Updated by Tatjana Dehler about 4 years ago
- Related to Feature #45088: mgr/dashboard: add report lookup URL to Telemetry module added
Updated by Lenz Grimmer almost 4 years ago
- Status changed from New to Pending Backport
- Target version set to v16.0.0
- Backport set to octopus
- Pull request ID set to 33462
Updated by Tatjana Dehler almost 4 years ago
- Copied to Backport #45334: octopus: mgr/dashboard: Provide an better workflow to "opt in" to enabling the telemetry mgr plugin added
Updated by Tatjana Dehler almost 4 years ago
- Related to Feature #45464: mgr/dashboard: telemetry module activation notification added
Updated by Nathan Cutler almost 4 years ago
- Status changed from Pending Backport to Resolved
While running with --resolve-parent, the script "backport-create-issue" noticed that all backports of this issue are in status "Resolved" or "Rejected".
Updated by Ernesto Puerta about 3 years ago
- Project changed from mgr to Dashboard
- Category changed from 132 to General