*yml* based setting to ship telemetry (and disable the UI to opt out)

[bmcconaghy]

setting in kibana.yml to both force opting in for telemetry and disabling the UI for opting out of it.

[elasticmachine]

Pinging @elastic/kibana-stack-services (Team:Stack Services)

[bmcconaghy]

@bleskes this is the issue for tracking Kibana work on opt in yml setting for cloud

[Bamieh]

@bmcconaghy does it make sense to have 2 configs for this?

telemetry.allowChangingOptInStatus: false;
telemetry.optIn: true;

[mikecote]

@Bamieh the other option could be a single config with 3 options. Something like mode: 'on' | 'off' | 'optIn'. I'm good either way.

Edit: I guess to not have telemetry, just disable the plugin.

[pmuellr]

There's already a banner config option, looks to be used as a boolean. Perhaps it has some other use, but the places it's used looks like it would prevent the banner from being displayed, when set to false:

kibana/src/legacy/core_plugins/telemetry/index.ts

Lines 45 to 50 in 1dcec9d

	config(Joi: typeof JoiNamespace) {
	return Joi.object({
	enabled: Joi.boolean().default(true),
	// `config` is used internally and not intended to be set
	config: Joi.string().default(Joi.ref('$defaultConfigPath')),
	banner: Joi.boolean().default(true),

https://github.com/elastic/kibana/search?q=telemetryBanner&unscoped_q=telemetryBanner

So, seems like we already support this. Note that if they banner hasn't been displayed, asking them to opt in or out, and they haven't specifically enabled it in advanced settings, then we assume they've opted out.

[mikecote]

Yeah so we need something to enable telemetry by default and prevent users from opting out. I'm thinking if enabled: true the banner automatically won't show. Then we would need to disable the APIs and UIs where the user would be able to toggle telemetry to off.

[pmuellr]

That's correct; if enabled is true, the banner won't be shown. And banner set to false does seem to prevent the banner from being displayed, if it's supposed to be displayed, based on a quick manual test.

We could use the same banner config to indicate the API should be disabled, and perhaps not provide the advanced settings section in the management app (assuming that's possible)

Perhaps not great overloading there, but OTOH, I'm a little wary of adding more config and complicating the existing code, compared to making use of an existing config in different places in the code ...

[Bamieh]

@pmuellr the banner is for hiding the opt-in banners, but they can still enable/disable opt-in by going to advanced settings. we want a config that removes the ability to change opt-in status completely (ie remove it from advanced settings, and the checkbox from license in additon to not displaying the banner and the welcome card).

@mikecote I am trying to think about all the use cases we might need in the future so breaking these configs as much as possible would be ideal.

allowChangingOptInStatus removes the ability to change opt-in status. Regardless if the user is opted in or not. This means that we'll remove all the banners and opt in checkboxes from advanced settings and license page.

telemetry.optIn: true will enable opt-in by default instead of the default opt-out. This will not prevent users from changing the opt in status via advanced settings.

The current default opt in status is null which is different from false: null prompts the user with the banner and welcome screen card, while false does not.

[bmcconaghy]

Remember there's also the advanced setting page, at the bottom:

So we'll need a setting that is distinct from the banner one, as this shows independent of the banner setting.

[dimatkach]

Will setting these options require to restart kibana? Any chance they can be made reloadable?

[bleskes]

@dimatkach these settings are fixed for all kibana instances on cloud- they are set to enable telemetry and remove the ui to disable. This will never change. I don’t think we need auto reload?

[dimatkach]

@bleskes I think, it would be nice to have auto reload in these situations:

• when we first enable it in cloud, if there are some 7.5 deployments already running
• if we need to disable it for some reason (or in some region? ESSP? IBM?), and/or re-enable afterwards
• when people upgrade ECE to a version that has this enabled (2.4?), while they already have some 7.5 deployments
• Legal comes up with a different process we have to follow before this can be enabled (maybe user has to accept new TOC explicitly or something)

[bleskes]

@dimatkach i think the ece point may be valid, depending on the tbd plan there. All the rest are safe to ignore imo. If it’s easy to do, I’m all for it. I wouldn't delay anything for it.