[ISSUE][Regression] Ability to turn off exporters (new / old)

[Langleu]

Describe the issue:

For dual-region we need to be able to turn off the exporters (old / new), so we can define them ourselves.
In 8.7 and prior we had the flag global.elasticsearch.disableExporters, which is now deprecated and has no functionality anymore.

In 8.8 I can see the global.exporter.enabled but that affects the old exporters but not the new. Additionally, it has a lot of or conditions that would still lead to them being enabled.

Even in the case of data-migration the old exporters would be disabled and supplied extra from the outside.

So ideally, we have 1 or 2 flags that disable old and / or new exporters.

Related source code:

• https://github.com/camunda/camunda-platform-helm/blob/main/charts/camunda-platform-8.8/templates/orchestration/files/_application-unified.yaml#L236
• https://github.com/camunda/camunda-platform-helm/blob/main/charts/camunda-platform-8.8/templates/orchestration/files/_application-unified.yaml#L275

Actual behavior:

It's currently impossible to turn off the new exporter or the old exporter fully.
The application side is already working on a flag that disables the auto-configuration of it but the Helm Chart would currently still define it.

Expected behavior:

Flags that allow for disabling the new and old exporters completely.

How to reproduce:

Logs:

Environment:

Please note: Without the following info, it's hard to resolve the issue and probably it will be closed.

• Platform: Dual-Region
• Helm CLI version: latest
• Chart version: 8.8 snapshot chart
• Values file:

[Langleu]

probably two flags so one can control better the old and new exporters.

# new exporter
global.exporter.camunda.enabled

# old exporter
global.exporter.zeebe.enabled

or we could re-use the multi-region flag to turn it off since it's linked to it and doesn't interfere with the UX.
If multi-region is enabled it's turned off, otherwise it will default to the same behaviour as now with all the or statements

[Langleu]

My current idea:

• https://github.com/camunda/camunda-platform-helm/blob/main/charts/camunda-platform-8.8/templates/orchestration/files/_application-unified.yaml#L236

To keep the previous UX, we base it on the regions and decide what to apply.
In case regions are equal to 2 or bigger it disables the old exporters, otherwise applies the normal behaviour we previously had.

    {{- if and
      (lt (int (default 1 .Values.global.multiregion.regions)) 2)
      (or
        (and .Values.global.elasticsearch.enabled .Values.global.exporter.zeebe.enabled)
        (and .Values.global.elasticsearch.enabled .Values.optimize.enabled)
        (and .Values.global.elasticsearch.enabled .Values.orchestration.migration.data.enabled)
      )
    }}

Or maybe fix it to just if regions is equal to 2. I don't have insight how 3+ regions are handled if we even have a customer using that. Could be same / similar or completely different. Highly depends on how the secondary storage is handled.
Or if regions > 2 and exporter.zeebe.enabled=false, could also be an idea.

alternative idea:

{{- if and
  (or
    (and .Values.global.elasticsearch.enabled .Values.global.exporter.zeebe.enabled)
    (and .Values.global.elasticsearch.enabled .Values.optimize.enabled)
    (and .Values.global.elasticsearch.enabled .Values.orchestration.migration.data.enabled)
  )
  (or
    .Values.global.exporter.zeebe.enabled
    (lt (int (default 1 .Values.global.multiregion.regions)) 2)
  )
}}

this would require both regions to be greater or equal 2 as well as explicitly the exporter disabled / enabled.

• https://github.com/camunda/camunda-platform-helm/blob/main/charts/camunda-platform-8.8/templates/orchestration/files/_application-unified.yaml#L275

We don't need to link it to regions but just use the new flag, which by default is true.

{{- if and (not (eq (include "orchestration.secondaryStorage" .) "none")) .Values.global.exporter.camunda.enabled }}

values differentiated in

global.exporter.camunda.enabled=true (new)
global.exporter.zeebe.enabled=false (old)

[Langleu]

PR with the alternative approach can be found here:

#4272

[Langleu]

closed by #4272