search

camunda / camunda-platform-helm

Camunda Platform 8 Self-Managed Helm charts
https://docs.camunda.io/docs/self-managed/overview/
Apache License 2.0
74 stars 138 forks source link

[ISSUE] identity.keycloak ingress not being rendered when using pre-8.5 configuration style #1665

Closed jessesimpson36 closed 6 months ago

jessesimpson36 commented 6 months ago

Describe the issue:

When I configure a separated ingress for keycloak, I find that it is not being used unless if I configure it using the new identityKeycloak key.

I suspect more options other than the ingress are affected by this issue, however, the missing ingress is the only thing I'm aware of right now.

To set this up, I have 2 values.yaml files. The only difference between the two is that one specifies 

identity:
  keycloak:
    ingress:
      ...

and the other uses the new key:

identityKeycloak:
  ingress:
    ...

SUPPORT-21602

Actual behavior: The keycloak ingress is not rendered when the option is under identity.keycloak.ingress.

Expected behavior: The keycloak ingress should be rendered for both styles of specifying options for keycloak in values.yaml

How to reproduce:

21602-identityKeycloak.yaml.txt 21602-identity.keycloak.yaml.txt

Both of these values.yaml files should output an ingress manifest for keycloak, however, only the identityKeycloak one outputs the ingress.

> helm template -f /tmp/21602-identityKeycloak.yaml.txt cpt camunda/camunda-platform --version 10.0.2 --show-only charts/identityKeycloak/templates/ingress.yaml 

---
# Source: camunda-platform/charts/identityKeycloak/templates/ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
...
> helm template -f /tmp/21602-identity.keycloak.yaml.txt cpt camunda/camunda-platform --version 10.0.2 --show-only charts/identityKeycloak/templates/ingress.yaml 

Error: could not find template charts/identityKeycloak/templates/ingress.yaml in chart

Logs:

Environment:

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

jessesimpson36 commented 6 months ago

https://github.com/camunda/camunda-platform-helm/blob/e9856ac22e57f30391e28afc1eb1c8d43db04473/charts/camunda-platform/templates/zeebe/z_compatibility_helpers.tpl#L24-L26

I suspect this part of the compatibility layer isn't working as intended.

jessesimpson36 commented 6 months ago

I've done a deeper investigation into this, and the summary is that helm renders each of the templates in a particular order. This bug is caused by some templates being rendered out-of-order. So consider the following hypothetical render order:

  1. keycloak ingress
  2. compatibility helper
  3. keycloak deployment
  4. keycloak service

In the above scenario, when "keycloak ingress" gets rendered, it will evaluate variables such as is identity.keycloak.ingress.enabled set to "true"? the answer is no, because the compatibility helper is the thing that sets identity.keycloak.ingress.enabled.

Because of this behavior, some files may get rendered with the expected variables, and some files may not. The ranking for the render order is defined by how many folders are above the template.

The compatibility helper is in the following path: templates/zeebe/z_compatibility_helper.tpl. The rank is 2 because it has 2 folders above it. However, the keycloak ingress is at the following path: charts/keycloak/templates/ingress.yaml, which has a rank 3, which means it will be rendered first.

So how do we get z_compatibility_helper.tpl to get a higher rank so that it renders first? We can deeply nest it in a bunch of folders to trick the render order.

If we put z_compatibility_helper.tpl in a nested folder such as templates/zeebe/1/2/3/4/5/6/7/8/z_compatibility_helper.tpl then the rank will be 10 which means it will be rendered before any template amongst our subcharts. (unless we one day have 4 or 5 subcharts within subcharts).

I have a test helm chart where I played around with that solution, as well as a helm integration test which makes it easier to step through helm code in a debugger.

I will also upload a text representation of the current render order that I extracted from a variable in helm:

render_order.txt