Remove Easy Telemetry

[yanavasileva]

Acceptance Criteria (Required on creation)

1. Engine
   • ProcessEngineConfigurationImpl - Remove configuration properties and related code that are not needed anymore.
     won't start up after an update
   • BootstrapEngineCommand - don't add telemetry lock and property
     • for updated instance, the database property/ies will be left there and they won't be used. Do we want to remove it?
   • TelemetryReporter and TelemetrySendingTask
     • Remove sending functionality. Keep general code so it can be used for fetching the diagnostic data without the interval to send HTTP requests.
   • IsTelemetryEnabledCmd
     • deprecate Java and REST API, so whoever uses it knows that is no longer function and can remove it but their code won't brake
     • empty out command, should always return false
   • TelemetryConfigureCmd
     • deprecate Java and REST API, so whoever uses it knows that is no longer function and can remove it but their code won't brake
     • empty out command, should do nothing
   • connect dependency - remove it and check if shading is working as expected
   • Loggers - remove all logging that is not used any longer
2. REST API
   • deprecate and empty out
   • remove tests
3. Distros, javaee, connect plugin
   • remove connect process engine plugin used for telemetryHttpConnector (sending HTTP requests for telemetry) and the a
   • exclude connect dependency
     • if users use the dependency for other reasons, they can add the dependency themselves (we can consider adding this to the migration guide)
4. Tests (CE and EE)
   • tests configuration files - remove telemetry endpoint property
   • tests - remove sending telemetry tests but leave and ensure diagnostic data API is tested
   • wiremock - remove where not needed anymore
5. Docs
   • Configuration pages - remove telemetry properties: process engine, quarkus, spring boot
   • Telemetry page - leave only collected data that can be used for the diagnostics, maybe rename/move the page. For transparency we can add that feature has been removed.
   • Migration page - document any breaking changes
     • feature removed
     • configuration properties removed
     • API deprecated and emptied
     • connect dependency removal
6. Optional
   • TelemetryReporter and TelemetrySendingTask
     • rename the classes to move away from telemetry as they will be used only for fetching diagnostic data
     • remove the TimerTask as it is not needed anymore

Hints

Links

• depended on by In Admin, remove telemetry configuration options #4484

Breakdown

### Pull Requests
- [ ] https://github.com/camunda/camunda-bpm-platform/pull/4486
- [ ] https://github.com/camunda/camunda-bpm-platform-ee/pull/962
- [ ] https://github.com/camunda/camunda-docs-manual/pull/1661
- [ ] https://github.com/camunda/camunda-bpm-platform/pull/4544

[yanavasileva]

To remove, no longer used: org.camunda.bpm.engine.impl.telemetry.dto.InternalsImpl.telemetryEnabled

camunda-bpm-platform/engine/src/main/java/org/camunda/bpm/engine/impl/telemetry/dto/InternalsImpl.java

Line 55 in 58a6857

protected Boolean telemetryEnabled;

It's not exposed in public Java API and not available in REST API at all.

[yanavasileva]

❓ Do we need migration test?
* No, as we don't have data to test from previous version to this.
❓ Can we remove the telemetry.lock from the sql scripts?

• No, since old engine should work with new database schema and the lock is needed during start up. However, the Database schema backwards compatibility doesn't mention that scenario. ref.
• Yes, since the property will be there for existing instances and not needed in new ones.

❓ If telemetry reporter is removed, do we need special handling for diagnostics endpoint?

• No, the diagnostics are collected per process engine node (installation).

[yanavasileva]

Existing database will have the telemetry.lock so we don't need to keep it.

[yanavasileva]

Docs PR is still work in progress.