[Task names in TaskManager] Rename "telemetry" to "usage"

[afharo]

Summary

Rename telemetry to usage to avoid confusion in support and users.

We've had a few open requests asking why they could see entries in the logs about tasks named after "telemetry" when they explicitly set telemetry.enabled: false or telemetry.optIn: false.

To avoid annoying users, let's use an alternative name when naming the tasks used for usage collection.

Checklist

Delete any items that are not applicable to this PR.

• Unit or functional tests were updated or added to match the most common scenarios

For maintainers

• This was checked for breaking API changes and was labeled appropriately

[afharo]

@elastic/kibana-alerting-services is it safe to simply rename the tasks like in this PR or do we need to apply any sort of migration to avoid the ones with the previous names to keep on running?

[afharo]

@elasticmachine merge upstream

[elasticmachine]

Pinging @elastic/kibana-app-arch (Team:AppArch)

[elasticmachine]

Pinging @elastic/kibana-telemetry (Team:KibanaTelemetry)

[elasticmachine]

Pinging @elastic/apm-ui (Team:apm)

[mikecote]

@elastic/kibana-alerting-services is it safe to simply rename the tasks like in this PR or do we need to apply any sort of migration to avoid the ones with the previous names to keep on running?

A couple of things:

• Renaming the task definition: This will cause existing tasks that reference the old name to fail at their next execution
• Renaming the task id: This will cause a secondary task to be created and leaving the old task failing

There isn't a good workaround that I can think of at this time other than creating back the old task definition to delete the old task. I think it might be easier to leave the ids and task definition names as they are.

[afharo]

Oh! @mikecote, thank you for confirming.

That's unfortunate. Maybe adding await taskManager.remove(oldId) is not that difficult. However, for how long are we supposed to keep that delete clause there (customers don't necessarily upgrade from minor-1 to minor (not even from major-1 to major)?

I'll close this PR for now.

Should we open an issue to improve the Task Manager to clean up tasks that have been registered on a previous version and not registered again in the new one after startup? Does it make sense?

[mikecote]

Maybe adding await taskManager.remove(oldId) is not that difficult. However, for how long are we supposed to keep that delete clause there (customers don't necessarily upgrade from minor-1 to minor (not even from major-1 to major)?

I think that could work, I think users are suppose to upgrade to the latest minor before upgrading to a major. This would mean in 8.0 you could cleanup the code.

Should we open an issue to improve the Task Manager to clean up tasks that have been registered on a previous version and not registered again in the new one after startup? Does it make sense?

This could be interesting, an issue can at least be opened to explore such option. If we feel it's best to go an alternate path, we can then close it. With the tight bandwidth in 7.x, there's no promise this would be done in the 7.x timeframe.

[TinaHeiligers]

@afharo since we can't easily rename the tasks, we need to find some other way to share knowledge to users about what telemetry tasks are actually for. @mikecote is there a way for us to add a description to a task when registering it?

[mikecote]

@TinaHeiligers you can use the title attribute in the task definition to set a description.

https://github.com/elastic/kibana/blob/master/x-pack/plugins/task_manager/server/README.md

Example:

taskManager.registerTaskDefinitions({
      // clusterMonitoring is the task type, and must be unique across the entire system
      clusterMonitoring: {
        // Human friendly name, used to represent this task in logs, UI, etc
        title: 'Human friendly name',
        ...
      },
});

[TinaHeiligers]

you can use the title attribute in the task definition to set a description.

@afharo for now, we can keep the changes to the title.

[afharo]

@TinaHeiligers the only problem is that we've seen errors like ES claiming something in the line of Failed to GET .kibana_task_manager/_doc/task:Actions-actions_telemetry or Failed cancelling task ID Actions-actions_telemetry, so the title is not helping much here.

I'll update them anyway in case we ever provide a UI management for the tasks 🙂

[afharo]

As agreed, updated titles only and leaving task IDs and types unchanged for now.

[afharo]

@elasticmachine merge upstream

[YulNaumenko]

Alerting changes LGTM

[afharo]

@elasticmachine merge upstream

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: 1a0ab2d

Metrics [docs]

✅ unchanged

History

• 💚 Build #77313 succeeded c61b76f
• 💚 Build #76877 succeeded 2f17f31
• 💚 Build #76139 succeeded a9d2f32
• 💔 Build #76110 failed 470f3ba

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

[smith]

APM changes look good.

[kertal]

KibanaApp Code LGTM, since just a title changed, didn't test, trust in Jenkins

[elasticmachine]

Pinging @elastic/kibana-core (Team:Core)