Closed ManuelDittmar closed 8 months ago
works if fullURL is provided.
global:
identity:
auth:
# Disable the Identity authentication for local development
# it will fall back to basic-auth: demo/demo as default user
enabled: true
# Disable identity as part of the Camunda core
identity:
enabled: true
fullURL: "http://identity:8080"
optimize:
enabled: true
# Reduce for Zeebe and Gateway the configured replicas and with that the required resources
# to get it running locally
zeebe:
clusterSize: 1
partitionCount: 1
replicationFactor: 1
pvcSize: 10Gi
zeebe-gateway:
replicas: 1
connectors:
enabled: true
inbound:
mode: disabled
elasticsearch:
master:
replicaCount: 1
# Request smaller persistent volumes.
persistence:
size: 15Gi
webModeler:
enabled: true
image:
pullSecrets:
# replace with the name of the previously created secret
- name: docker-registry
restapi:
mail:
smtpHost: smtp.example.com
smtpPort: 587
smtpUser: user
smtpPassword: secret
# email address to be displayed as sender of emails from Web Modeler
fromAddress: no-reply@example.com
postgresql:
enabled: true
Saw the bug too in default config. Using fullurl in identity fixed it for me.
Thanks for reporting that issue :+1:
@Ben-Sheppard if that's expected behavior from Identity, I will add a constrain in Helm to ensure that the user supply the fullURL
value.
I have two thoughts here:
Hmm seems like its this addition https://github.com/camunda/camunda-platform-helm/pull/1377/files#diff-be698369f3ab3270130fb11441ad7f467541c5e25d0ad445805fa0aa0c4251cfR32 - I can see why we added it (there was a requirement on our side to effectively have the internal Identity URL and the external URL but the helper method should rely on fallbacks if .Values.fullUrl
is not present.
Look again at the error messages it seems that the catch block if identity.fullUrl
is not set is causing the issue as it can default the $proto
but not find the host etc? Could you confirm that @aabouzaid ?
@Ben-Sheppard thanks for the info :+1:
The issue was coming from extra characters (newline and spaces) in the IDENTITY_URL
+ missing default value when no fullURL or Ingress is there.
It's been fixed in https://github.com/camunda/camunda-platform-helm/pull/1480 and https://github.com/camunda/camunda-platform-helm/pull/1481
Also with the new logic we have, the identity.fullURL
is not mandatory anymore so I've updated the docs and removed it from the values of the tests.
@aabouzaid Has this been backported to HC 9.3.x? A customer using HC 9.3.3 encountered this issue and applied the workaround of adding identity.fullURL.
Hi @aabouzaid, please let us know if this fix has been backported to HC 9.3.X. we are using HC 9.3.3 as Renz mentioned. and we are awaiting your reply. Thanks
From what I can see, this issue has not been backported to 9.3.x This fix was introduced at release 10.0.0
And the fix for the related issue was introduced at release 10.0.3
We will look to backport this fix
Describe the issue:
with the below values.yaml, identity fails to start. It only works if the fullURL is provided. This was not the case with 9.2.
Actual behavior:
Back-off restarting failed container identity in pod camunda-identity-846d96dfd-d8ffk_default(8bd8a2a7-60e7-4b6c-81bb-7bf72d86ffb6)
camunda-identity-846d96dfd-d8ffk 0/1 CrashLoopBackOff 3 (20s ago) 92s
Expected behavior:
Identity can be started successfully with default values.
How to reproduce:
helm install camunda camunda/camunda-platform --version 9.2 -f values.yaml
helm install camunda camunda/camunda-platform --version 9.3 -f values.yaml
Logs:
Environment:
Please note: Without the following info, it's hard to resolve the issue and probably it will be closed.