Find a good way to configure partitionCount in Optimize

Zelldon commented 2 years ago

See https://camunda.slack.com/archives/C02UT3T8DQR/p1650536952860079

Optimize needs to be configured with the partition count. Currently, this information is located in the Zeebe sub-chart. Helm doesn't allow sharing of information between child /sub-charts.

The following solutions I see:

We add a new property, which is globally available. Like: global.zeebePartitionCount The problem I see here is that currently, we have zeebe.partitionCount which people use. We could drop the property and print a warning if this property is still in use. If we want to keep the value: we could use the value of global.zeebePartitionCount in zeebe.partitionCount, to only configure one property. But this will not help with users which already use zeebe.partitionCount and are not aware of the new property.
We add just a new property in the Optimize sub chart and the user needs to configure the partition count in two places. In zeebe and optimize section.
I could investigate an idea I had recently. In the root we have access to all properties, so we might be able to deploy a config map for Optimize, which contains the properties from Zeebe.
Optimize can somehow self-detect the partition count like operate does, mentioned by JOSh here

blocks #126

npepinpe commented 2 years ago

I think the Operate team regretted doing the partition count detection, but I can't remember why. I think it's fine to have to specify it - it would potentially allow us to shard the installations later on.

What's wrong with option 1? Is there no way in Helm to have one value fallback to another if not specified?

Zelldon commented 2 years ago

The problem with one is that if users use zeebe.partitionCount and update to the new chart version, the new variable will not be updated. It is possible to reference other values BUT they need to be available when the template is evaluated.

Example:

We have:


zeebe:
  value: two # this is only available in zeebe sub chart

optimize: 
  value : three # this is only available in optimize sub chart

If we now introduce

global:

 otherKey: value

This will be available in all other charts and we can do things like:

zeebe:
  value: {{ .Values.global.otherKey }}

If zeebe chart access, it it will resolve to the value set in otherKey. But this works because it has access to the variable.

We can't do things like:

global:

 otherKey: {{ .Values.zeebe.value }}

If now optimize access global.otherKey this will fail since the values from Zeebe are not available.

Concluding: We can only do zeebe.value: {{ .Values.global.otherKey }}, which helps to update default value and reference the new property. But if the user already overwrites this variable than he wouldn't update the other value.

Do you get what I mean @npepinpe ?

npepinpe commented 2 years ago

Oh, I didn't realize we couldn't reference other charts. It makes sense, I guess :disappointed:

RomanJRW commented 2 years ago

I think the Operate team regretted doing the partition count detection

From memory, I think there was a potential error in the scenario where not all partitions had exported records. In this case, Operate would start up and incorrectly deduce based on the existing records that have been exported that there are less partitions than there really are in Zeebe. Configuration seems a much "safer" way of doing this. I think this is also why we never explored trying to do similar so far

Zelldon commented 2 years ago

After some discussions we decided to go with the simplest (and potentially more flexible) way, for now, means adding a property to the optimize sub-chart which sets the partitionCount.

We discussed in todays Team meeting the topic "Disabling Optimize" and "Partition count in Optimize". We agreed on keeping it simple and flexible as possible.

This means:

We will support for Optimize an separate toggle to turn off and on, even if identity is disabled

We will support for Identity an toggle

We will support an toggle for the web app authentication mechanism, might help later for Optimize id we want to support different mechanism.

This keeps our implementation simple and the usage flexible, with the downside that if the user wants to disable Identity he has to toggle three flags. We will see whether this will be an issue for the users or not.

Regarding the topic of partition count, same here to keep it simple for now we will add a separate value in the optimize chart. Means, if the user wants to increase the partitions he has to do it in zeebe and optimize, if he uses optimize. This allows us to keep the implementation easy to maintain and still flexible. We currently see no easy way to set it in one place without doing some breaking changes.

If we see complains about this a potential addition would be to add a global variable which can be set once and change the defaults of the existing partitionCounts to a reference to it. Like described above https://github.com/camunda/camunda-platform-helm/issues/286#issuecomment-1105212953

camunda / camunda-platform-helm

Find a good way to configure partitionCount in Optimize #286

Example: